架构是个让大家又爱又恨的话题，谁都可以说上两句，但又不一定所有人能把它说清楚。不过归根结底，你见得多了，想得多了，实践得多了，思考得多了之后，都可以最终达到领悟的状态。本文接下来就给大家提供一些基于Clean Architecture这本书的洞见。
首先，对一个软件项目的整体架构进行治理的首要目的是代码可读性，可复用性，可测性，可维护性，所以如果你的项目本身规模不大，比如一个只有一个功能的demo项目，使用简单的MVC架构，分目录归拢代码就能清晰在划分出对应职责，那这种时候你不需要花额外精力来治理架构
那么对于一个大型的且需要持续迭代的项目来说，架构治理会是一个必然的要求，因为随着代码量的增加，项目复杂度和改动成本的不断增加，以及随之而来的功能稳定性问题会是项目能否持续向前演进的关键。
今天我们主要说一下Clean Architecture这个技术流派是以什么出发点，用什么方法来解决架构问题。
软件架构面临哪些问题
- 代码复杂度
- 人员变动
- 重构
- 替换模块
所有这些都指向一个要求，能够让开发者不借助外力的情况下知道改哪些代码，怎么改
怎么解决呢
这本书系统地介绍了架构的相关知识，基于整洁架构的洋葱模型对工程代码进行分层从而实现关注点分离。降低项目维护成本，实现项目的“快稳狠”。
其它架构是怎么解决的
六边形架构（Hexagonal Architecture）
又称为端口与适配器（Ports and Adapters），由 Alistair Cockburn 提出，并在 Steve Freeman 与 Nat Pryce 的经典著作 Growing Object-Oriented Software 中得以推广。
洋葱架构（Onion Architecture）
由 Jeffrey Palermo 提出。
尖叫架构（Screaming Architecture）
出自作者Uncle Bos 2011年的一篇博客。
DCI 架构（Data-Context-Interaction）
由 James Coplien 与 Trygve Reenskaug 提出。
BCE（Boundary-Control-Entity）
由 Ivar Jacobson 在其著作 Object-Oriented Software Engineering: A Use-Case Driven Approach 中提出。
虽然这些架构在细节上有所不同，但它们非常相似。它们的共同目标是 关注点分离（Separation of Concerns） 。也就是都通过将软件划分为不同层次来实现这种分离。每种架构至少都有一个用于 业务规则（business rules） 的层，以及另一个用于 接口（interfaces） 的层。
这些架构产生的系统具备以下特性：
- 与框架无关
架构不依赖某些功能繁多的软件库的存在。这样你可以把框架当作工具来用，而不是被迫把系统塞进它们的局限里。 - 可测试
业务规则可以在没有 UI、数据库、Web 服务器或其他外部元素的情况下进行测试。 - 与 UI 无关
UI 可以轻松更换，而无需修改系统的其他部分。例如，可以将 Web UI 替换为命令行 UI，而无需改动业务规则。 - 与数据库无关
可以将 Oracle 或 SQL Server 替换为 Mongo、BigTable、CouchDB 等，而业务规则不会受到影响。 - 与任何外部机构无关
业务规则对外部世界一无所知。
下面将讲到的整洁架构的图示，正是试图将这些架构整合成一个可执行的统一理念。
整洁架构怎么解决呢
用书里面的话来说判断一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该成本很低，并且在系统的整个生命周期内一直都能维持这样的低成本，那么这个系统的设计就是优良的。如果该系统的每次发布都会提升下一次变更的成本，那么这个设计就是不好的
最重要的原则是依赖原则，依赖只能向内。也就是内层不应知道任何外层的细节，包括但不限于函数、类、变量、数据格式或任何其它实体。
