这篇文章是软件架构编年史的一部分，一系列关于软件架构的文章。在这些文章中，我写了我对软件架构的了解，我如何看待它，以及我如何使用这些知识。如果您阅读了本系列以前的文章，那么本文的内容可能更有意义。
大学毕业后，我从事了高中教师的职业，直到几年前，我决定放弃它，成为一名全职软件开发人员。
从那以后，我总是觉得我需要找回失去的时间，尽可能多地、尽可能快地学习。因此，我有点沉迷于试验、阅读和写作，特别关注软件设计和体系结构。这就是我写这些帖子的原因，来帮助我学习。
在我的上一篇文章中，我写了很多我学过的概念和原则，以及我是如何推理的。但我认为这些只是拼图的一部分。
今天的帖子是关于我如何将所有这些部分组合在一起的，我似乎应该给它起个名字，我称它为显式架构（Explicit Architecture）。此外，这些概念都“通过了它们的考验”，并被用于高要求平台上的生产代码中。一个是SaaS的e-com平台，在全球拥有数千个网络商店，另一个是市场，在两个国家都有一个消息总线，每个月处理超过2000万条消息。
- 系统的基本模块
- 工具
- 将工具和交付机制连接到应用程序核心
- 端口
- 主适配器或驱动适配器
- 辅助或被驱动适配器
- 控制反转
- 应用程序的核心组织
- 域服务
- 域模型
- 应用程序层
- 领域层
- 组件
- 组件之间共享的数据存储
- 每个组件隔离数据存储
- 解耦的组件
- 触发逻辑在其他组件
- 从其他组件获取数据
- 控制流
系统的基本模块
我首先回顾一下EBI和端口及适配器架构。它们都明确区分了哪些代码是应用程序内部的，哪些是外部的，以及哪些用于连接内部和外部代码。
此外，端口和适配器体系结构明确标识了系统中的三个基本代码块:
- 是什么使得运行一个用户界面成为可能，不管它是什么类型的用户界面;
- 系统业务逻辑，或应用程序核心，由用户界面使用，以实际使事情发生;
- 基础构架代码，它将我们的应用核心与数据库、搜索引擎或第三方api等工具连接起来。
应用程序核心是我们真正应该关心的。是代码允许我们的代码做它应该做的事情，是我们的应用程序。它可能使用多个用户界面(渐进式web应用程序、移动应用程序、CLI、API等)，但是实际执行工作的代码是相同的，并且位于应用程序内核中，不管什么UI触发它，都应该是一样的。
可以想象，典型的应用程序流从用户界面中的代码开始，通过应用程序核心到基础设施代码，然后返回到应用程序核心，最后向用户界面交付响应。
工具
远离系统中最重要的代码(应用程序核心)，我们拥有应用程序使用的工具，例如数据库引擎、搜索引擎、Web服务器或CLI控制台(尽管后两个也是交付机制)。
虽然将CLI控制台与数据库引擎放在同一个“bucket”中可能感觉有些奇怪，尽管它们有不同类型的用途，但它们实际上是应用程序使用的工具。关键的区别在于，虽然CLI控制台和web服务器用于告诉应用程序执行某些操作，但是数据库引擎是由应用程序执行某些操作的。这是一个非常相关的区别，因为它对我们如何构建将这些工具与应用程序核心连接起来的代码有很强的影响。
将工具和传送机制连接到应用程序核心
将工具连接到应用程序核心的代码单元称为适配器(端口和适配器体系结构)。适配器是那些有效地实现代码的适配器，这些代码将允许业务逻辑与特定的工具通信，反之亦然。
告诉我们的应用程序做某事的适配器称为主适配器或驱动适配器，而由我们的应用程序告诉我们做某事的适配器称为辅助适配器或驱动适配器。
端口
然而，这些适配器不是随机创建的。创建它们是为了将特定的入口点安装到应用程序核心(一个端口)。端口只不过是工具如何使用应用程序内核或应用程序内核如何使用它的规范。在大多数语言及其最简单的形式中，这个规范，即端口，将是一个接口，但它实际上可能由几个接口和dto组成。
需要注意的是，端口(接口)属于业务逻辑内部，而适配器属于业务逻辑外部。要使此模式正常工作，最重要的是创建适合应用程序核心需求的端口，而不是简单地模仿工具api。
主适配器或驱动适配器
主适配器或驱动适配器围绕一个端口，并使用它来告诉应用程序核心要做什么。它们将来自交付机制的任何东西转换为应用程序核心中的方法调用。
换句话说，我们的驱动适配器是控制器或控制台命令，它们在构造函数中注入一些对象，这些对象的类实现控制器或控制台命令所需的接口(端口)。
在更具体的示例中，端口可以是控制器所需的服务接口或存储库接口。然后将服务、存储库或查询的具体实现注入并在控制器中使用。
或者，端口可以是命令总线或查询总线接口。在这种情况下，将命令或查询总线的具体实现注入控制器，然后控制器构造命令或查询并将其传递给相关总线。
辅助或被驱动适配器
与围绕端口的被驱动适配器不同，驱动适配器实现一个端口和一个接口，然后将其注入到应用程序核心中，无论哪里需要端口(类型暗示)。
例如，假设我们有一个需要持久化数据的简单应用程序。所以我们创建一个持久性接口,满足其需要,用一个方法来保存数组的数据和方法来删除表中的一行的ID。从那时起,无论应用程序需要保存或删除数据,我们需要在其构造函数实现持久化的对象我们定义的接口。
现在我们创建一个特定于MySQL的适配器来实现这个接口。它将具有保存数组和删除表中的一行的方法，并且我们将在需要持久性接口的地方注入它。
如果在某个时候我们决定改变数据库供应商，比如PostgreSQL或MongoDB，我们只需要创建一个新的适配器来实现PostgreSQL特定的持久化接口，并注入新的适配器而不是旧的。
控制反转
关于此模式需要注意的一个特征是，适配器依赖于特定的工具和特定的端口(通过实现接口)。但是我们的业务逻辑只依赖于端口(接口)，它被设计成适合业务逻辑需求，所以它不依赖于特定的适配器或工具。
这意味着依赖的方向是朝向中心的，这是建筑层面的控制原则的倒置。
尽管如此，创建端口是为了满足应用程序的核心需求，而不是简单地模仿工具api，这一点非常重要。
应用程序的核心组织
Onion架构采用DDD层，并将它们合并到端口和适配器架构中。这些层旨在为业务逻辑、端口和适配器的内部“六边形”带来一些组织，就像端口和适配器一样，依赖关系的方向是向中心的。
应用程序层
用例是可以由应用程序中的一个或多个用户接口在应用程序核心中触发的流程。例如，在CMS中，我们可以有普通用户使用的实际应用程序UI、CMS管理员使用的另一个独立UI、另一个CLI UI和web API。这些ui(应用程序)可以触发特定于其中一个或由其中几个重用的用例。
用例在应用层中定义，这是DDD提供的第一层，由Onion Architecture使用。
这一层包含作为第一类公民的应用程序服务(及其接口)，但它也包含端口和适配器接口(端口)，其中包括ORM接口、搜索引擎接口、消息传递接口等等。在我们使用命令总线和/或查询总线的情况下，这一层是命令和查询各自的处理程序所在的地方。
应用程序服务和/或命令处理程序包含展开用例(业务流程)的逻辑。一般来说，他们的职责是:
- 使用存储库查找一个或多个实体;
- 告诉那些实体去做一些域逻辑;
- 并使用存储库再次持久化实体，有效地保存数据更改。
命令处理程序可以用两种不同的方式使用:
- 它们可以包含执行用例的实际逻辑;
- 它们可以在我们的体系结构中用作简单的连接块，接收命令并简单地触发存在于应用程序服务中的逻辑。
使用哪种方法取决于上下文，例如:
我们是否已经准备好了应用程序服务并正在添加命令总线?
命令总线是否允许指定任何类/方法作为处理程序，或者它们是否需要扩展或实现现有的类或接口?
这一层还包含应用程序事件的触发，这些事件表示用例的一些结果。这些事件触发的逻辑是用例的副作用，比如发送电子邮件、通知第三方API、发送推送通知，甚至启动属于应用程序不同组件的另一个用例。
领域层
再往里，我们有域层。这个层中的对象包含数据和操作数据的逻辑，这是特定于域本身的，它独立于触发逻辑的业务流程，它们是独立的，完全不知道应用层。
域服务
如前所述，应用服务的作用是:
- 使用存储库查找一个或多个实体;
- 告诉那些实体去做一些域逻辑;
- 并使用存储库再次持久化实体，有效地保存数据更改。
然而，有时我们会遇到一些涉及不同实体的域逻辑，不管它们是否属于同一类型，我们觉得域逻辑不属于实体本身，我们觉得那个逻辑不是它们的直接责任。
因此，我们的第一反应可能是将逻辑放在实体之外的应用程序服务中。然而，这意味着该域逻辑将不能在其他用例中重用:域逻辑应该远离应用程序层!
解决方案是创建一个域服务，它的角色是接收一组实体并在其上执行一些业务逻辑。域服务属于域层，因此它对应用层中的类一无所知，比如应用程序服务或存储库。另一方面，它可以使用其他域服务，当然还有域模型对象。
域模型
在最中心的是域模型，它不依赖于它之外的任何东西，它包含表示域内某些内容的业务对象。这些对象的示例首先是实体，但也包括值对象、枚举和域模型中使用的任何对象。
域模型也是域事件“活动”的地方。当特定的一组数据发生更改时，将触发这些事件，并将这些更改随身携带。换句话说，当一个实体发生更改时，将触发一个域事件，它将携带更改后的属性新值。例如，这些事件非常适合用于事件源。
