架构整洁之道-22章-整洁架构

按照更好架构设计出的系统特点：

• 独立于框架
• 可被测试
• 独立于UI
• 独立于数据库
• 独立于任何外部机构

• 外层的变化不影响内层的逻辑
  • 外层变化同时修改对应适配器么
• 层次划分-按需划分并非固定多少层
  • 图22.1中所显示的同心圆只是为了说明架构的结构，真正的架构很可能会超过四层。并没有某个规则约定一个系统的架构有且只能有四层。然而，这其中的依赖关系原则是不变的。也就是说，源码层面的依赖关系一定要指向同心圆的内侧。层次越往内，其抽象和策略的层次越高，同时软件的抽象程度就越高，其包含的高层策略就越多。最内层的圆中包含的是最通用、最高层的策略，最外层的圆包含的是最具体的实现细节。
• 边界跨越
  • 利用依赖反转原则DIP可以变更控制流的运转方向以符合架构层次设计的合理性或者说规范，内层不应该直接调用外层的服务
  • 原始控制流：控制器-用例交互-展示器，变化后：控制器-用例输入层-用力交互层-用例输出层-展示器
  • 交互层没有直接调用展示器，而是调用一个内层结构，而展示器是对其实现
    实例：
    

层次：展示、控制器、业务、数据/视图外层、控制器、业务用例、领域模型实体
转换：控制器通过inputBoundary依赖业务用例，用例层依赖数据实例，由数据实例通过DataAccessInterface去和数据存储交互，通过OutputBoundary这个内部用例转换器+外层Presenter的实现让内部数据并没有直接对外产生影响，内部的UseCaseInterceptor只影响和交互OutputBoundary

小结：如你所见，遵守上面这些简单的规范并不困难，这样做能在未来避免各种令人头疼的问题。通过将系统划分层次，并确保这些层次遵守依赖关系规则，就可以构建出一个天生可测试的系统，这其中的好处是不言而喻的。而且，当系统外层的这些数据库或Web框架过时的时候，我们还可以很轻松地替换它们。

• 合适的架构可以趋利避害，利：技术+领域共建让系统整体符合业务发展，害：不断变化的外部组件直接影响内部核心逻辑
• 层次的划分标准：展示、控制、用例、领域，实际上我的系统可以按照现有情况和未来发展方向给出自己的封层、例如预处理拆出的调度层