DDD006-领域驱动架构图

领域驱动设计是创建对问题空间的共同理解，通过对话、代码和图表无处不在地加强。DDD 的共享理解增强了协同效应和一致性，提高了可持续交付价值的能力 - 理想情况下，在产品的使用寿命内。正如一个系统的架构，通过图表表达，是一个有利可图的途径，以加强DD的共享模式。

以红色突出显示：其中架构图可以使用域驱动的方法具有优势。

从 Wrox 发布的域驱动设计的模式、原则和实践中修改和借用的图表 我在最近几个项目中使用的一个想法是创建域驱动架构图的一般框架。

当专注于领域驱动设计的战略方面时，此框架是将您对域的理解映射到建议的软件架构的有用起点。 在这篇文章中，我概述了 框架。它源于西蒙布朗的特殊的C4框架，这一直是一个职业生涯加速的启示对我来说。

系统上下文图

我认为，让人们对系统进行更高级别的概述至关重要 - 用户、使用案例、主要内部系统，以及基本上需要监控的您无法控制的高风险外部依赖。在 C4 命名中，这是系统上下文图，可用于记录我们的领域驱动架构。 此图在将非技术利益相关者参与潜在显示停止器或关键拦截器的项目和计划级别问题方面具有难以想象的有效 性。此图也非常适合适应项目技术和非技术新来者。 我们可以使用系统上下文图来加强我们的共享模型，使用无处不在的语言列出用户、系统名称和以下所示的交 互。

显示高级别信息的系统上下文图，抽象出边界上下文。

如果您能保持清晰度，那么在系统上下文图上显示您的边界上下文（如下图）是可以的。请注意，相比之下，上面的图表如何消除边界上下文，并将新系统作为一个单一概念来保持图清晰。

对于边界上下文较少的系统，可以更容易地向他们显示系统上下文图

我的门槛是7。如果我的图表上有超过 7 个框，它可能显示的细节有点太多，因此我将避免在此级别显示边界上下文。

绑定上下文映射

传统上称为上下文图，但有资格在这里作为边界上下文图完全消除系统上下文图，这种高级别的可视化显示边界上下文之间的关系，使每个人都有一个清晰的内部景观理解。团队关系、沟通模式、整合策略和跨团队依赖性都是有用的信息类型，可以用一个边界上下文地图来突出，正如和蔼可亲的阿尔贝托·白兰度尼 http://www.infoq.com/articles/ddd-contextmapping 所熟练解释的那样。

我花了很多时间对他们的界限背景和团队之间如何联系缺乏系统性 的看法。这可能对每个人都有害，尤其是当您是一个开发人员，他不明白系统中您的部分如何融入整体，这会使您在向业务利益相关者解释端到端流程或优化系统级利益方面束手无策。

从 Wrox A 界限上下文地图发布的领域驱动设计的模式、原则和实践中获取的示例（绑定）上下文图是一种可能的解决方案。如上所示，它可以是高水平，低维护和低努力。它可以极大地提高共享理解，同时强调低效率和组织问题，因此您可以在技术和非技术人员的帮助下及早发现它们。

对于使用异步、事件驱动的通信以及每个受约束的上下文的系统由单个团队拥有，没有共享的依赖性，边界上下文图效果较差，但仍值得。您也许能够表达有关系统上下文和业务使用案例图的重要信息，并跳过此图。但要小心。

绑定上下文可部署

在某些时候，您需要用技术现实和约束来验证您的软件架构。这是有边界的上下文可部署图的目的。 哪些服务（将）存在于有限制的上下文 中？他们如何互动？主要的技术选择是什么？此插图用于回答这些问题。

通常，一个有限制的上下文可部署图是每边界上下文的最有效方法，让每个团队决定是否需要/想要一个并控制维护它。 此图对于确定团队将构建的内容、让新团队成员跟上速度以及教育外部团队（如运营团队）了解可部署人员的工作情况 非常重要。此图还可用于突出显示可围绕组织共享的知识或可避免的重复。 在 C4 命名中，这称为容器 图。然而， 我认为我们可以在 Ddd 中更具体， 尤其是当容器这个词现在与码头工人和微服务如此密切地相关时。 下面是一个示例绑定上下文可部署图，显示有边界的上下文及其组成的部署 单位。这是从我的介绍到领域驱动设计架构研讨会的样本。

前期设计太多？以我的经验不一些。此图与我们的理解一样演变，为整个团队提供了我们试图构建的清晰图景，同时在早期阶段强调某些类型的问题（例如兼容性）。

业务使用案例图

领域驱动设计策略的一部分是协调有界限的上下文，以执行完整的业务使用案例。然而，如果每个边界上下文都有它自己的图表，我们就无法清楚地看到此端到端的图片。因此，我创建每个重要用例的专用端到端图。

创建图表，让域名专家表示将充分的业务使用案例作为实施的前兆，从而增强信心。此插图借用了 Wrox

发布的领域驱动设计的模式、原则和实践我所能想到的最有表现力的名字是业务使用案例图，因为这正是我试图传达的。这就是我脑子里提到他们的方式。也许即使完整的端到端业务使用案例图也会更好。在域驱动设计的模式、原理和实践中，我将这种图称为组分图，取自C4 框架。

该图如下所示，用于演示通过事件驱动的架构流式事件。

付款拒绝使用案例图，我称之为由 Wrox

发布的领域驱动设计的模式、原则和实践中的组件图本图显示了被拒绝的付款业务使用案例。我将此图称为领域驱动设计模式、原则和实践中的组分图，但由于术语组件的模糊性，我对此决定感到有点遗憾。 我将其标记为组件图，因为每个箭头都是事件，每个事件都有发布该事件的组 件。此外，该图避免了技术细节，因此它也不是容器图。在书中，一个组件是部署单元。正如西蒙·布朗所说，这些年来，我逐渐意识到，术语组件可能意味着任何事情——一个类，一个模块，一个部署单元，一个建筑抽象，甚至还有一个JIRA字段的组件。

因此，我决定最好不要使用术语组件。

在这些类型的图表中，我想展示边界上下文如何协同工作，以执行完整的业务使用案例。那么，以他们说明的用例命名的企业使用案例图怎么样？

域概念图

每个复杂的领域都有复杂的业务规则、政策和工作流程。在在代码中建模之前，您需要与域专家合作创建强大的神经通路，让您有信心实现。 在这些情况下，图表是 有用的。旨在与域专家合作，以业务语言创建无技术行话的图表，作为创建与问题域高度一致的域模型的蓝图。

Simon Brown 将这些图表称为 " 可部署级别以下但高于类级别的组 件。我脑子里称它们为域名概念图，因为我只想用无处不在的语言尽可能清晰地表达域名概念。 以下是我创建的域概念图示例，作为领域驱动设计架构研讨会的介绍示例 。

此域名概念图显示了在电子商务域中如何计算线项目折扣策略。这是在业务的语言：BSOP、RPLD、FLIP 等都是从无处不在的语言中获取的条目，尽管它确实包含一些技术必需品，如存储库。 您应该创建多少张这些 图表？视情况而定。有时，您可以在白板上创建它们，并在编写代码后将其扔掉。我的启发性是维护域概念图，以制定基本政策，这些基本政策是企业价值主张或概念的关键，而这些概念无法在代码中充分表达。

只是一个准则

适应新问题域需要时间。单词可以具有特定的含义，而单词的字典定义只有松散的联系，利益相关者可以对什么对业务很重要产生截然不同的意见。然而，绿地或棕地，当你陷入一个软件项目，你期望交付。

信息，清楚地传达重要的技术和非技术信息，如关键业务差异化，组织约束，以及建议/现有的技术配置是跟上速度的关键。