架构整洁之道-软件架构(二)
19、策略和层次
- 策略：策略泛指业务逻辑 算法 流程控制，这些所实现的方法都是由一些稳定的高层级的方法组合而来的。
- 层次
- 高层组件:距离输出、输入越远它的层级越高
- 底层组件:直接输出、输入层级越低
在开发过程中使用组件合并成一个业务实现。而不是面条式的编程。这样在底层组件中的紧急修改不会影响更高层次的业务逻辑。
20、业务逻辑
- 是软件设计中具体实现功能的逻辑，这是系统价值的体现和用途。
- 在实现业务逻辑是应该清晰获取到改业务需要实现的方法进而对这些方法进行组合，从而得出业务的用例或者说业务的链条。
- 这部分讲的更像是边界的划分，根据业务模块划分业务的边界。
- 业务输出、和输入和交互页面输出和输入要区别开来。逻辑输入、输出就只是逻辑使用，不对交互页面负责，交互页面的输入输出使用和业务输入输出分割开来。
21、尖叫的软件架构
- 软件架构应该是基于业务创建的软件架构，不考虑技术的实现细节。是使用哪种技术应该是最后进行技术探讨的时候实现的。对于一个应用程序不管是哪中交互比如：（web,客户端），都不进行规定，都可以实现。
- 架构是工具不是生活信条，采用哪种技术对系统有帮助，或者采用哪种架构成本更低；架构应该是对系统的支持，不应该让框架限制系统的发展。
22、整洁架构
- 不管是六边形架构、DIC架构、BCE架构都有一个共同的目标：按照不同的关注点对软件进行切割，就是说架构将软件切割成不同的层，至少有一层是只包含软件的业务逻辑的。
- 独立于框架：这个架构不应该依赖于框架中的某个方法。
- 可被测试：这些业务逻辑可脱离细节（页面，数据库，服务，等）；
- 独立于UI：适用不同的展现形式；
- 独立于数据库：可以支持各类数据库；
- 独立于外部机构：业务逻辑不需要知道其他外部接口的存在；
- 依赖关系
-
- 低层级的依赖只依赖于高层级。任何高层级的代码依赖不应该依赖于底层级。不能让低层级的业务变更影响到高层级的实现。
- 业务实体：对于C#就是这一类中的public方法能被不同的应用复用。
- 层次越深代码的抽象程度越高：包含的高层策略越多。所以也就是目前看到的市面上的orm框架的对应不同的实现很多：比如mysql sqlserve oracle。
