掌握洋葱架构，完成DDD更顺利！
本帖最后由 草帽路飞UU 于 2022-10-13 15:56 编辑领域是一个知识的范畴。它指的是我们的软件所要模拟的业务知识。领域驱动设计的中心是领域模型，它对一个领域的流程和规则有着深刻的理解。洋葱架构实现了这一概念，并极大地改善了代码的品质，降
低了复杂性，并且支持不断发展的企业系统。
一、为什么要用洋葱架构？
领域实体是核心和中心部分。洋葱架构是建立在一个领域模型上的，其中各层是通过接口连接的。其背后的思想是，在领域实体和业务规则构成架构的核心部分时，尽可能将外部依赖性保持在外。
·它提供了灵活、可持续和可移植的架构。
· 各层之间没有紧密的耦合，并且有关注点的分离。
· 由于所有的代码都依赖于更深的层或者中心，所以提供了更好的可维护性。
· 提高了整体代码的可测试性，因为单元测试可以为单独的层创建，而不会影响到其他的模块。
· 框架/技术可以很容易地改变而不影响核心领域。例如，RabbitMQ 可以被 ActiveMQ 取代，SQL可以被 MongoDB 取代。
二、原则
洋葱架构是由多个同心层构成，它们相互连接，并朝向代表领域的核心。它是基于控制反转（Inversion of Control，IoC）的原则。该架构并不关注底层技术或框架，而是关注实际的领域模型。它是基于
以下原则：
1、依赖性
圆圈代表不同的责任层。一般来说，我们潜入得越深，就越接近于领域和业务规则。外圈代表机制，内圈代表核心领域逻辑。外层依赖于内层，而内层则对外圈一无所知。通常情况下，属于外圈的类、方
法、变量和源代码依赖于内圈，但是反过来也一样。
数据格式/结构可能因层而异。外层的数据格式不应该被内层使用。例如，API 中使用的数据格式可以与 DB 中用于持久化的数据格式不同。数据流可以使用数据传输对象。每当数据跨层/跨界时，它应该
以方便该层的形式出现。例如，API 可以有 DTO，DB 层可以有 Entity Objects，这取决于存储在数据库中的对象与领域模型的不同。
2、数据封装
每个层/圈封装或隐藏内部的实现细节，并向外层公开接口。所有的层也需要提供便于内层消费的信息。其目的是最小化层与层之间的耦合，最大化跨层垂直切面内的耦合。我们在较深的层定义抽象接
口，并在最外层提供其具体实现。这样可以确保我们专注于领域模型，而不必过多地担心实现细节。我们还可以使用依赖性注入框架，比如 Spring，在运行时将接口与实现连接起来。例如，领域中使用的存
储库和应用服务中使用的外部服务在基础设施层实现。
3、关注点的分离
应用被分为若干层，每一层都有一组职责，并解决不同的关注点。每一层都作为应用中的模块/包/命名空间。
4、耦合性
低耦合性，可以使一个模块与另一个模块交互，而不需要关注另一个模块的内部。所有的内部层都不需要关注外部层的内部实现。
三、洋葱架构层
让我们通过一个创建订单的用例来了解架构的不同层和它们的职责。当收到一个创建订单的请求时，我们会对这个订单进行验证，将这个订单保存在数据库中，更新所有订单项目的库存，借记订单金额，
最后向客户发送订单完成的通知。
1、领域模型/实体
领域实体是领域驱动设计的基本构件，它们被用来在代码中为通用语言的概念建模。实体是在问题域中具有唯一身份的领域概念。领域实体封装了属性和实体行为。它应该是独立于数据库或网络 API 等特
定技术的。例如，在订单领域，订单是一个实体，并具有像 OrderId、Address、UserInfo、OrderItems、PricingInfo 这样的属性以及像 AddOrderItems、GetPricingInfo、ValidateOrder 这样的行为。
2、领域服务
领域服务负责保持领域逻辑和业务规则。所有的业务逻辑应该作为领域服务的一部分来实现。领域服务由应用服务协调，以服务于业务用例。它们不是典型的 CRUD 服务，通常是独立的服务。领域服务
负责复杂的业务规则，如在处理订单时计算价格和税收信息，保存和更新订单的订单库接口，更新购买物品信息的库存接口等。
它包含了对其目标非常关键的算法，并且将用例作为应用的核心来实现。
3、应用服务
应用服务也被称为“用例”，是只负责协调请求步骤的服务，不应该有任何业务逻辑。应用服务与其他服务交互，以满足客户的请求。让我们考虑一下用例，用一个物品清单创建一个订单。我们首先需要
计算价格，包括税收计算/折扣等，保存订单项目并向客户发送订单确认通知。定价计算应该是领域服务的一部分，但涉及定价计算、检查可用性、保存订单和通知用户的协调工作应该是应用服务的一部分。
应用服务只能由基础设施服务调用。
4、基础设施服务
基础设施服务也被称为基础设施适配器，是洋葱架构的最外层。这些服务负责与外部世界交互，不解决任何领域的问题。这些服务只是与外部资源通信，没有任何逻辑。例如：外部通知服务、GRPC 服务
器端点、Kafka 事件流适配器、数据库适配器。
5、可观察性服务
可观察性服务负责监控应用。这些服务有助于执行以下任务：
·数据收集（指标、日志、痕迹）：主要使用库/侧线来收集代码执行期间的各种数据。
· 数据存储：使用能够集中存储所收集的数据的工具（分类、索引等）。
· 可视化：使用允许你对收集的数据进行可视化的工具。
一些例子包括 Splunk、ELK、Grafana、Graphite、Datadog。
四、测试策略
洋葱架构的不同层有不同的职责，相应地也有不同的测试策略。测试金字塔是一个很好的框架，它规定了不同类型的测试。属于领域模型、领域服务和应用服务的业务规则应通过单元测试进行测试。当我
们移动到外层时，在基础设施服务中进行集成测试更有意义。对于我们的应用，端到端测试和 BDD 是最合适的测试策略。
五、微服务
当孤立地看待每个微服务时，洋葱架构也适用于微服务。每个微服务都有自己的模型、自己的用例，并定义了自己的外部接口，用于检索或修改数据。这些接口可以用一个适配器来实现，该适配器通过公
开 HTTP Rest、GRPC、Thrift Endpoints 等连接到另一个微服务。它很适合微服务，在微服务中，数据访问层不仅包括数据库，还包括例如一个 http 客户端，以从另一个微服务，甚至从外部系统获取数据。
六、应用结构和层数
应用结构和层，包括层如何映射到模块以及它们之间的依赖关系。它还描述了对不同层使用什么样的测试策略。
七、模块化与打包
有两种方法来组织应用的源代码：
·要么我们可以将所有的包放在一个模块/项目中
· 要么将应用分为不同的模块/项目，每个模块/项目负责洋葱架构中的一个层
这在很大程度上取决于应用的复杂性和项目的规模，将源代码分为多个模块。在微服务架构中，模块化可能有意义，也可能没有意义，这取决于复杂性和用例。
八、框架、客户端和驱动
基础设施层由网络或服务器的框架、数据库的客户端、队列或外部服务组成。它负责配置和缝合所有的外部服务和框架。洋葱架构提供了解耦功能，因此在任何时候交换技术都会变得更容易。
九、我们需要每个层吗？
将我们的应用分层组织有助于实现关注点的分离。但我们需要所有的层吗？也许需要，也许不需要。这取决于用例和应用的复杂性。根据应用的需要，也可以创建更多的抽象层。例如，对于没有很多业务
逻辑的小型应用，拥有领域服务可能没有意义。无论哪一层，依赖关系都应该是从外层到内层。
十、总结
洋葱架构在开始时可能似乎有些困难，但是在业界已经得到了普遍的认可。这是一种让软件易于演进的强有力架构。通过把应用划分为几层，可以使系统更加易于测试、维护和移植。它有助于在旧框架过
时时轻松采用新框架/技术。与其他架构风格类似，如六边形、分层、简洁的架构等，它为常见问题提供了一个解决方案。
页:
[1]
