什么是三位一体架构Trinity Architecture？ – Oregor

这里提出的Trinity Architecture是后端企业应用程序的架构模式。它源于采用依赖性倒置原理（DIP）的典型4层架构。它非常适合（但不限于）领域驱动设计（DDD）应用程序。

三位一体的三大支柱是：

• 所述领域模型（DOMAIN）
• 公共应用程序编程接口（API）
• 辅助服务（AUX）

Trinity强调平衡不受控制的灵活性和一致性。它提供了八个顶级模块的具体实施指南。

依赖规则是：

圆圈内的圆圈：外圈取决于内圈。

圆圈外的圆圈：外圆使用（客户端）或实现（细节）内部圆。

Github提供支持 工具 和库 。

流行架构模式的简要概述

一开始，当计算机科学出现在50年代/ 60年代时，就没有我们今天所知的架构。开发人员通过优化算法和数据结构来解决问题。

软件架构一词在20世纪90年代初才开始流行。原因是客户端 - 服务器系统的兴起。使用客户端 - 服务器系统，出现了多层体系结构的模式。

后来，在同一个十年中，出现了分层架构。分层的系统将系统分解为逻辑层而不是物理层。

在2000年代，基于依赖性倒置原则出现了新的架构模式。他们的主要目标是解决分层架构的紧耦合问题。

1. 多层架构

有史以来最流行的架构是多层架构。该模式不指定层数，而是一个简单的规则：一层可以与其下面的任何层耦合，但从不与高于它的层耦合。

许多团队可能会争论分层架构中合适的层数。

Martin Fowler（2002）建议三层。（1）表现，（2）领域，和（3）数据源。

Eric Evans（2003）建议四层。（1）用户界面，（2）应用，（3）领域，以及（4）基础设施。

分层架构的好处

• 简单
• 一致性
• 关注点分离

分层架构的缺点

• 缺乏内置的可扩展性
• 隐藏的用例
• 业务逻辑可能从UI扩展到数据库
• 交换框架和技术很麻烦，如果不是禁止的话
• 复杂的测试过程
• 存在太多，不必要的层次的风险

2. 依赖倒置原则

Robert C. Martin 于1996年制定了依赖性倒置原则（DIP）。它代表“ SOLID ”原则中的字母“ D ” 。今天，它是面向对象编程中最着名的原则之一。

DIP的正式定义是：

A.高级模块不应该依赖于低级模块。两者都应该依赖于抽象（接口）。

B.抽象不应该依赖于细节。细节（类）应该取决于抽象。

Vaughn Vernon（2013）演示了如何在典型的4层架构中应用DIP：

通过这种简单的反转，领域层是所有其他层依赖的域层。这种方法消除了与基础设施层的直接耦合。

3基于DIP的架构

在2000年代中期之后，应用程序架构出现了一系列想法。

• 端口和适配器（六角形），Alistair Cockburn，2005年
• 洋葱杰弗里巴勒莫，2008年
• 罗伯特C.马丁的清洁建筑，2012/2017年

虽然它们的细节各不相同，但它们的目标是相同的。它们都旨在通过DIP 更好地分离关注点。我们可以称这个系列的架构模式同心Concentric。

根据Robert C. Martin的说法，他们背后的依赖规则是：

源代码依赖项必须指向内部，指向更高级别的策略。

基于DIP的架构的好处

• 独立于UI
• 独立于数据库和其他外部系统
• 独立于技术特定的库和框架
• 可互换的基础设施模块
• 任意数量和类型的客户端
• 可测试

基于DIP的架构的缺点

• 复杂
• 缺少模板（洋葱除外）
• 前几十年的模糊术语
• 易受错误依赖和模块结构的影响（如果做得不对）
• 如何选择模式？

三位一体的形成

Trinity的目标是解决基于DIP的架构的缺点。在本节中，将形成它的形式。所需的步骤是：

• 从典型的4层开始，定义通用与特定层
• 定义严格和轻松的依赖关系
• 应用DIP
• 包括应用程序模块并构成Trinity体系结构

1.定义通用和特定层

Trinity的起点是典型的4层，正如埃文斯在2003年所提出的那样。当时，诸如REST之类的技术对IT社区来说是未知的。我们现在将术语调整为最新标准：

1. 客户端、
2. API、
3. 领域层
4. 辅助层

看看上面Vaughn Vernon（2013）转换到这四个层的映射过程：

• 用户界面层 - >客户端：今天应用程序不仅限于单个用户界面客户端。相反，可以有许多客户端。它们可以存在很多形式（即REST客户端，Web MVC客户端等）
• 应用层 - >（公共）API：应用层本身不区分公共和内部服务。在这里，我们将它强制为一个特定的层，通过将其重命名为（Public）API来表示其目的。
• 领域层 - >领域层：领域层是应用程序的核心，已经是一个非常特殊的层，它仍然保持原样。
• 基础设施层 - >辅助：基础设施可能令人困惑，特别是对于初级开发人员。人们可能只考虑物理服务器，例如数据库或消息服务器。但这不是唯一的例子。例如，基础设施也是实现复杂加密算法的服务。因此，我们用术语辅助替换术语基础设施。辅助程序更好地描述了有助于应用程序目的的任何内容。

2. 定义严格和宽松的依赖关系

在分层体系结构中，层之间有两种类型的耦合：

• 严格：只允许耦合到它下面的一层。
• 相关：任何更高级别的层都可以耦合到它下面的任何层。

应用DIP

在下一步中，我们将DIP应用于除了第一个以外下面的所有层，即API客户端。这是最关键的一步。

• API只定义了DTO的和抽象。
• Domain领域层定义的模型，它需要所有的抽象。因此，我们删除了与AUX层的耦合。
• AUX层定义了应用程序所需的DTO和抽象。
• API细节： 实现的API抽象使用的领域和AUX抽象。
• DOMAIN详细： 实施的DOMAIN抽象
• AUX细节： 落实的AUX抽象
• API客户端使用的API抽象，不是API详细信息。

由于前三个模块仅定义抽象，因此它们与框架无关。

包括应用程序（APP）模块的实战图

接下来，我们包括应用程序模块，它是引导应用程序所必需的。它还负责配置APP，横切关注点等。

通过旋转和重新组织块，我们现在可以形成三位一体架构。

最下面一行是Trinity Core，它们与框架/技术无关。上排是三位一体组合。它提供实现和使用Trinity Core。

另一种观点是圆形的，在文章的顶部描绘。

三位一体架构

1. 核心

三位一体建筑的三大支柱是：

• 域：域模型
• API：公共应用程序编程接口
• AUX：辅助服务

这些模块中的每一个都不依赖于其余任何一个。他们的作用是仅定义DTO，模型和抽象。他们也应该不会有任何关于框架相关的库的依赖关系。唯一可接受的例外是如果需要，使用框架特定注释。

2 API详细信息

该API详细是连接三个独立的组件的API，AUX和DOMAIN的。

它的作用是通过使用Domain和Auxiliary模型以及抽象来实现API。除了特定于框架的注释之外，API Detail仍然是框架不可知的。

3 API客户端

该体系结构支持添加任意数量的API客户端。该API客户端只依赖于抽象API和不域模型或辅助服务。通过这种方式，我们确保每个用例始终都有一个应用程序入口点。

4 AUX详细信息

该AUX细节提供应用程序所需的实现。您应该根据角色将细节分成不同的模块。例如：

• 文档存储
• 短信服务
• SMTP服务
• 等等

5 域详细信息

该层详细提供了应用程序所需的实现。您应该根据角色将细节分成不同的模块。例如：

• 持久保存数据库
• 领域服务
• 支付网关
• 模板引擎
• 等等

6 APP

Bootstraps并配置应用程序。

相关工具和工作

一个 三位一体的架构的演示 for Java是可在Github上。

模块的名称与Trinity Architecture图中使用的模块名称相比为1：1。

Java的Trinity Scaffolder

使用 Trinity Scaffolder可以 用 Java 生成自己的项目。

trinity4J

trinity4J 是一组面向Java应用程序的域驱动设计库。它非常适合Trinity Architecture。

PolyGenesis

Trinity Architecture是一个名为 PolyGenesis 的更大项目的 一部分 。

PolyGenesis 是跨语言自动代码生成的开源平台。它侧重于 DDD和 UI。

结论

​​​​​​​Trinity Architecture的特点是：

• 清晰的术语和明确定义的模块结构
• 框架独立核心（API，AUX，DOMAIN）
• 任意数量的API客户端，域详细信息和辅助详细信息
• 可互换的技术和框架
• 可测试
• 更好地分配团队成员
• 学习曲线低
• 支持工具和库