查看原文

IT 行业有不少带名字的架构方法论，例如 Hexagonal Architecture, Onion Architecture, Screaming Architecture, DCI, BCE；但纵使细节不同，总体是差不多的流程：相同的目标，不同的点拆开考虑，分层处理，层层相套，层中有商业逻辑，层间接口相通信。这些架构设计出来的系统也有相似的特征：独立运行，可测试，UI 方便调整，数据库可替换，外部依赖可替换，等等。

系统分层从里到外分别是业务逻辑，用例，控制层，外部接口层(UI, DB, Web, ...)。只能外层依赖内层，不能内层依赖外层。在代码里面，基本原则是外层代码里声明的东西，是不可以在内层代码里提及的，包括函数，类，变量，等等。类似的，外层使用的数据格式也不应该让内层使用。

Entities 封装了企业的 Business Rules，可以是一个类，也可以是一套数据结构和方法的接口。这些 Entities 可以被企业内部各种其它应用消费。

Use Cases 封装了应用级别的 Business Rules，是 Entities 的实现级别的抽象。它定义了 Entities 如何组装出数据流，如何完成一个个用例。

Interface Adapters 是个黏合层，将 Use Cases 和 Entities 的数据转为数据库或 Web 要用的数据格式。

Frameworks and Drivers 是最外层，包括数据库和 Web 框架，一般你不需要写这一层的代码。

这四层不是绝对的，你完全可以再加新的层以适配需要。但是 The Dependency Rules 依然适用：代码依赖总是朝内不朝外。