The Clean Architecture

Question

在过去的几年中，我们已经看到了关于系统框架的一些想法 :

• Hexagonal Architecture(六角架构) (a.k.a. Ports and Adapters) 这种架构是由 Alistair Cockburn 提出的，并由 Steve Freeman 和 Nat Pryce 在他们的书 Growing Object Oriented Software 中提出。
• Onion Architecture(洋葱架构) 提出者是 Jeffrey Palermo。
• 尖叫架构(Screaming Architecture) 提出者是 Uncle Bob（就是这篇文章的作者）。
• DCI 架构 提出者是 James Coplien 和 Trygve Reenskaug。
• BCE 架构 提出者是 Ivar Jacobson。在他的书《Object Oriented Software Engineering: A Use-Case Driven Approach》中有大量提及对这种架构的说明。

虽然这些文章在细节上有所不同，总体来说是非常相似的。它们关注点分离，通过将软件划分成层达到分离效果。每层最少包含一个业务规划或者接口。

这些架构有以下特点：

1. 独立框架
   这些架构不依赖某些特定库的加载，允许你使用框架作为工具，不会限制你的系统；
2. 可测试
   业务规划在没有 UI 界面，数据库，网页服务器或者其他外部元素的情况下进行测试；
3. 独立于 UI
   UI 很容易改变，而不用改变系统的其他部分，网页界面可以被控制台界面替换，同时还不用改变业务规划； 4.独立于数据库
   你可以切换到 Oracle，SQL Server，Mongo，BigTable，CouchDB 或者其他类型数据库，业务规则不与数据库绑定； 5.独立于任何外部代理
   事实上你的业务规划根本不需要知道外面的世界

在这篇文章顶部的图表是将这些架构的理念集成在一起。

依赖规则

同心圆代表软件的不同区域，一般情况下，越接近中心位置软件的级别会变得越来越高，外圆圈是机制，内圆圈是策略。

覆盖规则使得架构遵循依赖规则，这条规则表明，源代码只能向内依赖，内侧圆环不了解关于外侧圆环的一起，原则上，外圈圆环声明的名称不需要在内侧圆环中提到，其中包括函数，类，变量或者其他软件实体的名字

出于同样的原因，在外圆圈中使用的数据格式不应该使用在内圆圈，特别是格式是由外圆圈的框架产生的情况，我们不希望外圆圈影响内圆圈的内容

实体

实体封装项目范围内的业务规则，一个实体可以是一个对象的方法，或者是一组数据结构和功能.只要在项目中实体被不同的应用所使用即可。

如果你没有项目，只是单纯的写一个应用程序，那么这些实体就是应用程序的业务对象.它们封装的最普通，最高级的规则.当外部变化时，它们最有可能改变，例如，你不希望这些对象被一个更改的页面导航或者安全影响，改变特定应用程序的操作不应该影响实体层。

用例

在此层应用的业务规则包含应用特定的业务规则，他封装并实现了所有的系统用例，这些用例编排数据的流入和流出的实体，指示这些实体用在它们项目范围内的业务规则到达用力的目标。

我们不希望改变层时影响实体，也不希望层被外部的改变所影响，例如数据库，用户界面或者任何的共同框架的改变，此层与这部分是隔离开的。

我们这样做，不过是希望改变应用程序的操作时影响软件层的用例，用例详细信息改变时，这一层的代码也会受到影响。

接口适配器

这层软件是一个转化数字的适配器，从格式最方便的用例和实体转化为格式最方便的一些外部机构，如数据库或者网页，这一层完全包含 GUI 的 MVC 架构，代理者，视图，控制器都属于这一层，该模型可是只是从控制器传回到用例，然后从用例到代理和视图的数据结构。

同样的，在这一层数据被转换，从形式最方便的实体和用例转化成形式最方便的使用持久框架，即数据库.内圈里的任何代码不应该知道关于数据库的任何事情.如果这个数据库是 SQL 数据库，所有的 SQL 应该被限制在这一层，尤其是在这层对数据库的操作。

另外，在这一层其他适配器需要将数据从外部形势（如外部服务) 转化成内部形式的用例和实体。

框架和驱动程序

最外层一般由框架和工具组成，如数据库，web 框架等.一般来说，你不会在这一层写太多代码，而是贴代码传达到内层圆圈内。

这一层有很多细节，网页是一个细节，数据库是一个细节，我们保持外层的这些细节收到更少的破坏。

只有四个圆环?

不，圆圈只是传达意思，你可能会发现你使用到的不仅仅是这四个，没有规定你必须使用这四个圆环，然后，依赖规则始终适用，源代码始终向内依赖.越往圆圈内侧抽象水平越高，最外面的圆圈为低一级的具体细节.越往圆圈内侧抽象和封装的层次更高，最内侧圆层次最高，最普通.

跨越边界

该图的右下方是一个我们如何穿越边界的例子，它展示了控制器和代理者与下一层用例进行通信.注意控制流，开始于控制器，通过用例移动，结束于代理者的执行.还要注意源代码的依赖关系，指向内侧用例。

我们通常使用 依赖倒置原则 解释这个明显的矛盾 s 像 Java 语言，例如，我们会编排接口和继承的关系，使源代码在跨越边界的右侧点依赖反对控制流.

例如，考虑用例需要调用的代理.然而不需要直接调用，因为这将违反相关性规则:在外圈中的名称不需要在内圈中提及.因此，我们在内侧圆环中调用接口（这里显示的用例输出端口)，在外侧圆环实现它.

相同的技术应用在跨越边界的系统结构中，无论控制流会在什么方向，我们以动态多态性的优势创建源代码依赖性，反对控制流，使得我们能够符合依赖规则。

什么是数据跨越边界

通常跨越边界的数据是一种单纯的数据结构，可以使用基本的结构或者简单的数据进行传输.或者数据可以单纯的在函数中调用，或者你可以打包成一个 hashMap，或构造成一个对象，重要的是分离，操作简单，通过数据结构跨越边界。我们不想通过实体和数据作弊，不希望数据结构有任何一种依赖违反依赖规则。

例如，很多数据库框架响应查询返回一个方便的数据格式，我们称之为行结构.我们不希望向内跨越行结构，这将违反依赖规则，因为这会迫使内侧圆环了解外侧圆环的一些东西。

因此，当我们跨越边界传输数据时，它总是使用最方便内圆环的格式。

结论

符合这些简单的规则并不难，并会为你省掉很多前进过程中头疼的问题，通过软件分层，顺应依赖规则，创建一个系统在本质上是可以检测的，意味着拥有其本身的好处.当任何一个系统的外部部件过时时，如数据库或者 Web 框架，你可以使用最少的忧虑替换掉那些过时的元素。