DDD领域驱动设计系列二

在这一部分中，我将讨论我最喜欢的一种架构，称为“洋葱架构”。尽管如此，请允许我首先回顾一下，到目前为止，我们对DDD的了解如下：

DDD是关于我们如何从业务角度设计软件，而不是从技术角度。为此，我们必须在设计过程中与领域专家（又称业务专家）一起工作，这样我们才能与业务需求保持一致。这个过程总是从我们称之为无处不在的语言开始（即，我们需要在设计和实现过程中使用标准术语）。随后，将复杂域分解为更小的子域，称为有界上下文，并仔细定义用于在单个有界上下文之间通信的边界和契约。因此，每个有界上下文对另一个上下文来说都是一个黑匣子（只关心契约接口，不需要关心实现细节，因为它是从外部隐藏的）。

此外，在设计和实现过程中还需要避免一些陷阱。在对问题域进行建模时，这些都是以数据为中心的思维方式，关注实体、存储库等实现细节，而不是核心概念、通用和特定的技术术语，关注数据库事务而不是业务事务。

好的，现在让我们从主题开始，好吗：-）。

洋葱建筑是杰弗里·巴勒莫创造的。如果你听说过Alistair Cockburn的六边形体系结构（又称端口和适配器），那么洋葱式体系结构的想法实际上就是从这种六边形体系结构中得到启发的。

尽管您实现了DDD，但您不必使用Onion体系结构。而且您也不必为了应用洋葱架构而被迫使用DDD。两者都是相互独立的。因此，您可以自由地在DDD中使用Onion体系结构以外的其他体系结构（即使是传统的体系结构，如MVC，也仍然适合DDD）。然而，洋葱架构是一个强有力的候选者，适合DDD。

洋葱建筑与传统建筑有什么不同？让我们先看看传统的，然后再来洋葱。

在传统架构中，应用程序的结构由三层/层组成，如下所示：

正如我们所看到的，在这个特定的体系结构上，每一层高度依赖于它下面的层，并且每一层通常也依赖于一些公共基础设施（例如框架或实用服务）。在这种体系结构中，由于在每一层之间创建了耦合（每一层耦合到它下面的层，每一层通常耦合到各种基础设施关注点），因此很难对关注点进行分离。是的，为了在我们的系统中创建组件之间的交互，耦合是很重要的，但是我想说的是，这个特定的架构创建了不必要的耦合。

例如，假设团队决定使用SpringBoot构建代表基础架构层的微服务。随后，几年后，团队决定将框架更改为另一个框架，或者干脆放弃SpringBoot。使用这种体系结构，如果不在其他层进行任何调整（更改），就很难部署新框架，因为每一层都与框架（基础设施）层高度耦合。因此，团队有可能打破包含所有业务逻辑（业务域）的当前业务层。请记住，一个好的系统应该有一个标准MECE（相互排斥、全面详尽），即“松散耦合、高度内聚”。因此，您在系统中创建的耦合越多，您就需要付出更多的努力来更改系统并将其分解为独立的小部分。

另一方面，最大的问题（也是最常见的）是UI和业务逻辑与数据访问的耦合。可传递依赖项仍然是依赖项。如果业务逻辑不存在，UI将无法工作，就像如果数据访问不存在，业务逻辑将无法工作一样。数据访问频繁更改，并且每当数据访问更改时，您还需要使用此特定体系结构调整/更改业务层。还有，我以前提到过吗？更改包含业务规则的业务层将给公司带来很大的风险，尤其是当业务已经稳定且当前系统已被公司用户广泛使用时。

这就是为什么洋葱建筑来拯救它：-）。请看下面的洋葱架构图。

洋葱架构有很多方面，但主要目标是它如何控制耦合。你需要记住的基本规则是，所有的耦合都朝向中心。例如，在图示中，我们可以说：

• “基础设施”层将了解“应用程序服务”、“域服务”和“域模型”。
• “应用程序服务”将了解“域服务”和“域模型”。
• “域服务”只知道“域模型”。
• “域模型”只知道它自己。

内层不会也不应该知道外层。因此，“域模型”不知道“域服务”、“应用程序服务”和“基础设施”层。与“域服务”相同，它不知道“应用程序服务”和“基础设施”层，等等。

在最中间，我们看到了“域模型”，它代表了组织/公司（即我们正在尝试构建的应用程序）模型的状态和行为。在域模型周围是其他行为更多的层，其中层的数量可以变化（即，对层的数量没有限制）。

“应用程序核心”将粘合所有层，如“域模型”、“域服务”和“应用程序服务”（同样，层的数量可以不同，这意味着我们可以有更多层，而不仅仅是这3层）。

“域模型”就是中心，因为所有耦合都朝向中心，所以“域模型”必须只耦合到前面提到的自身。通常，“域模型”由一组称为存储库接口的接口组成，这些接口为系统中的对象提供保存和检索机制。因此，我可以说“域模型”定义了对象系统行为的契约，特别是用于保存和检索机制的契约。记住，只有接口（而不是实现）。我们可以稍后将实现留在不同的层（即基础结构层）。

外层（即“基础设施”层）是为经常更改的内容保留的。这些东西应该与“应用程序核心”隔离开来。UI、自动化测试、数据库访问、NetworkAccess、FileAccess属于此“基础设施”层。

微服务体系结构与域驱动设计（DDD）的关系

微服务体系结构

第一件事：让我们描述一下微服务体系结构是关于什么的。

微服务体系结构是一种体系结构模式，它专注于开发/构建小型、可重用和可扩展的服务。微服务使我们能够将我们的大型系统分解为多个独立的协作过程，从而有助于避免使用难以维护的大型整体式应用程序，特别是当您有大型项目和大型团队时。

当您必须为多语言设备（如可穿戴设备、物联网（IoT）、移动设备、台式机和web）创建服务时，微服务也非常有用。

微服务本身并不是一个新名词。它由PeterRodgers博士于2005年提出，他提到了基于SOAP的微网络服务。自2010年以来，它变得越来越受欢迎。

微服务体系结构的关键是：

• 它可以在堆栈、框架和/或使用的语言方面独立部署。
• 它被部署为一个小型服务，始终专注于做好一件事，即域驱动服务。
• 定义良好的接口和最少的功能。
• 避免级联故障和同步调用-针对故障的反应式设计。
• 每个服务都有自己的数据，并使用事件/消息与其他服务通信。
• 每个服务都是独立部署的，并且与其他服务（通常在自己的容器中运行）隔离，并且可以自动伸缩。

主要目标是为您提供一小部分独立的服务，这些服务在不同的环境中独立运行，但可以相互通信（紧密内聚）。正如我们所知，耦合是一种双头野兽。一方面，紧密耦合的代码很难测试、维护/重用，并且通常表现出“打鼹鼠”错误行为（即修复一个错误很可能会产生一个或多个新错误）。另一方面，一定量的耦合也是必要的，因为完全解耦的代码什么都不做；因此，耦合是必要的，但应谨慎管理。我们称之为“紧密耦合/紧密耦合”

微服务的好处

• 易于作为单个组件进行扩展。
• 易于部署并减少部署时间，即您可以在不中断任何其他模块的情况下部署每个模块。
• 由于其较小的代码大小，易于维护，并且您可以拥有一个小型的、专注的团队。

微服务挑战

• 在分布式服务中很难实现强一致性。
• 与单片应用程序相比，调试和跟踪问题更加困难。

一旦您实现了微服务，您还将面临许多其他挑战。然而，这将取决于您如何通过遵循一些众所周知的最佳实践来设计和管理您的微服务，如API管理、流量管理、服务监控等。如果有机会，我将尝试在稍后的另一系列文章中对它们进行封装。

DDD与微服务的关系如何？

如前所述，在微服务中，我们构建每个服务只为一件事服务，并且做好一件事。每个服务也与其他服务隔离。在这个问题上，DDD原则可以帮助我们通过所谓的“有界上下文”来保持服务的小范围

随后，DDD将通过您与领域专家建立的沟通，帮助您调查和了解您的领域和所有子域。通过了解您的域和子域，您将了解映射上下文以及所有子域之间的交互方式，这将有助于您设计和选择微服务体系结构的类型以及用于实现它们的方法，无论是反应式方法、编排方法还是混合式方法。。。这将取决于您对所从事领域的了解。每种方法都有利弊，需要根据项目和您的领域知识进行评估。DDD将帮助您对此事做出决定。

原文地址：https://yauritux.medium.com/ddd-part-iii-a4ef18ef9e03