The Clean Architecture

2011次阅读 | 发布于5年以前

原文链接 : The Clean Architecture

Robert Martin

译者:zimoguo

校对者:Mr.Simple

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

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》中有大量提及对这种架构的说明。

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

这些架构有以下特点:

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

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

依赖规则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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