the-clean-architecture

系统架构

我是本际云服务器推荐网的小编小本本。过去几年，我们已经看到了一系列关于系统架构的想法，包括：六边形架构（接口与适配器）、洋葱架构（Onion Architecture）、Screaming Architecture、DCI和BCE。这些架构有很多共同的点，尽管它们细节上有所不区别。它们都有相同的目标，那就是关注点分离，它们都是通过将软件分层来实现这种分离，每个组件至少有一个用于业务规则的层和另一个用于接口的层。

the-clean-architecture

这些架构中每一个都会产生这样的系统：

独立的框架：该架构不依赖于某些特性软件库的存；
可测试的（Testable）：可以在不依赖UI、数据库、Web服务器或任何其他外部依赖的情况下进行测试；
独立于UI：UI可以轻松的更改，而无需更改系统的其余部分。例如用控制台UI(终端)代替WebUI，而不需要更改业务规则；
独立于数据库：你可以切换底层数据库，你的业务规则不应该于数据库绑定；
独立于任何外部依赖：你的业务规则根本不了解外部世界。

软件分层模型

本文顶部的图是尝试将所有这些体系结构集成到一个可行的想法中的尝试。同心圆表示软件的不同领域。一般来说，随着软件的发展，软件会越来越高级（可以简单理解为分层越多）。越靠近外部的圆代表一种机制，越内部的圈代表一种政策。

依赖性规则是一个软件架构很重要的规则。该规则定义了源码性依赖只能指向内部，内层不需要关注任何外层的逻辑。内层的代码不能够引用外层的代码，包括函数、类、变量等。

软件架构中的不同层

下面我们来讲讲软件架构中不同层的作用：

实体（Entity）：实体封装了企业范围的业务规则。实体可以是一个具有方法的对象，也可以是一组数据结构或函数，只要实体可以被企业多个应用程序使用，都可以成为实体。实体封装了最通用和最高级的规则。当某些外部变化时，它们变化的可能性最小。例如，你不可希望当修改一个前端页面时，需要修改这些实体对象。对任何外层的修改都不会影响到实体层。
用例（UseCases）：这一层通常是应用程序的业务规则（Application Specific），它封装并实现了应用程序的所有用例，这些用例编排流入和流出实体层的数据，通过这实体所实现的企业业务规则实现用例业务规则。我们不希望这一层的改变影响到实体层，同时也不会希望外层如数据库的实现影响到这一层。
接口适配（InterfaceAdapters）：这一层的软件（或模块）是一组适配器，用来将用例层获取的数据转换为外层依赖（数据库，HTTP服务器）的数据格式。例如GUI的MVC结构通常在这一层实现。实图、演示者和控制器都属于这一层。在这一层中数据会从用例层的结构装换持久性框架的结构比如数据库。这一层不需要关注任何数据库实现的逻辑。
框架和驱动程序（Frameworks and Drivers）：最外层通常是由框架和工具组成，如数据库、Web框架，通常情况下这一层不需要有太多的代码，只是一些粘合下层的代码。这一层是所有细节所在，WEB是一个细节，数据库是一个细节，我们将这些放在外面，方便后续修改而不需要改动底层。