干净的架构The Clean Architecture.docx

干净的架构TheCleanArchitecture
这是著名软件大师Bob大叔提出的一种架构，也是当前各种语言开发架构。干净架构提出了一种单向依赖关系，从而从逻辑上形成一种向上的抽象系统。
我们经常听说过如下各种架构：
HYPERLINK"http://alistair.cockburn.us/Hexagonal+architecture"六边形架构HexagonalArchitecture(也称为端口和适配器)这是由AlistairCockburn提出，被SteveFreeman和NatPryce在他们的书籍HYPERLINK"http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627"GrowingObjectOrientedSoftware中采取的。
HYPERLINK"http://jeffreypalermo.com/blog/the-onion-architecture-part-1/"OnionArchitecture作者JeffreyPalermo
HYPERLINK"http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html"ScreamingArchitectureBob大叔
HYPERLINK"http://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208/"DCI由JamesCoplien和TrygveReenskaug推动
HYPERLINK"http://www.amazon.com/Object-Oriented-Software-Engineering-Approach/dp/0201544350"BCEIvarJacobson在他的书籍ObjectOrientedSoftwareEngineering:AUse-CaseDrivenApproach提出
虽然这些架构在细节上都略有不同，但他们都非常相似。它们都具有相同的目标，那就是分离关注。他们都通过软件分层来实现这种分离。至少有一个层代表业务规则，而另一个层用于接口。
这些架构产生的系统特点是：
独立的框架.这样的架构并不依赖与应用软件的具体库包，这样可以将框架作为工具，而不必将你的系统都胡乱混合在一起。
可测试.业务规则能够在没有UI和数据库或Web服务器的情况下被测试。
UI的独立性.UI改变变得容易，不必改变系统的其余部分，一个WebUI能被一个控制台或专门的图形UI替代,这些读不必更改业务核心规则。
数据库的独立性.你能够在Oracle或SQLServerMongo,BigTable,CouchDB,或之间切换,.你的业务规则不会和数据库绑定
独立的外部代理，其实你的业务规则可以对其外面的技术世界毫无所知，比如是否使用了MVC或DCI都可以不关心。
这种干净的架构图如下：

依赖规则DependencyRule
上图中同心圆代表各种不同领域的软件。一般来说，越深入代表你的软件层次越高。外圆是战术实现机制，内圆的是战略核心策略。
使此体系架构能够工作的关键是依赖规则。这条规则规定源代码只能向内依赖，在最里面的部分对外面一点都不知道，也就是内部不依赖外部，而外部依赖内部。这种依赖包含代码名称，或类的函数，变量或任何其他命名软件实体。
同样，在外面圈中使用的数据格式不应被内圈中使用，特别是如果这些数据格式是由外面一圈的框架生成的。我们不希望任何外圆的东西会影响内圈层。
实体Entities
实体封装的是企业业务规则，一个实体能是一个带有方法的对象，或者是一系列数据结构和函数，只要这个实体能够被不同的应用程序使用即可。
如果你没有编写企业软件，只是编写简单的应用程序，这些实体就是应用的业务对象，它们封装着最普通的高级别业务规则，你不能希望这些实体对象被一个页面的分页导航功能改变，也不能被安全机制改变，操作实现层面的任何改变不能影响实体层，只有业务需求改变了才可以改变实体。
用例UseCases
在这个层的软件包含应用指定的业务规则，它封装和实现系统的所有用例，这些用例会混合各种来自实体的各种数据流程，并且指导这些实体使用企业规则来完成用例的功能目标。
我们并不期望改变这层会影响实体层.我们也不期望这层被更外部如数据库UI或普通框架影响，这层也是因为关注而外部分离的。
我们期望应用层面的技术操作都不能影响用例层，如果需求中用例发生改变，这个层的代码才会发生改变。
接口适配器InterfaceAdapters
这一层的软件基本