此过程为您提供了学习和实际应用领域驱动设计（DDD）各个方面的分步指南 - 从围绕组织的业务模型进行定位到编写领域模型。

使用此过程将指导您完成使用DDD思维方式设计软件系统的每个基本步骤，因此您可以专注于业务挑战，而不会同时学习DDD而不知所措。

一旦你经历了这个过程的几次迭代，你将拥有基本的DDD理论和实践经验，以更深入地了解DDD。然后，您将能够适应和改进流程，以满足您在任何情况下的需求。在实际项目中，您经常会在这些步骤之间来回跳跃。

此过程适用于初学者。它不是一个线性的步骤序列，您应该将其标准化为最佳实践。领域驱动设计是一个进化的设计过程，需要在知识和设计的各个方面不断迭代。

DDD Starter Modelling Process

何时使用 DDD 入门建模过程？

如果您不熟悉DDD或只是不确定从哪里开始，此过程可以减少您的认知负荷。它将指导您完成以下方案，可能还有其他方案：

启动绿地项目

在新项目开始时，您需要考虑的事情数量可能会非常多。此过程的一次或两次迭代可以帮助您奠定基础。

开始棕地迁移

在开始对遗留系统进行现代化改造之前，此过程的几次迭代可以帮助您发现为目标体系结构创建愿景所需的基本信息。

启动一项主要工作计划

当启动新计划涉及许多团队的重大投资时，必须涵盖流程中的8个步骤。此过程可以指导您完成前几次迭代。

探索您的领域，寻找新的学习机会

软件开发是一个学习过程。您可以随时应用 DDD 入门建模流程来发现新的见解、发现新的机会，或者只是在团队中分享知识。

评估项目的当前状态

此过程可以作为评估当前系统与域和业务模型的一致性的基础。

重组团队

松散耦合的体系结构使团队能够并行工作而不会被阻止。松散耦合的架构也必须与域中的耦合保持一致。此过程将帮助您设计与您的域一致的软件体系结构和团队结构。

练习或学习DDD

当您不熟悉DDD并希望练习，或者您想教其他人域建模的不同方面时，此过程是理想的选择。重要的是要传达这个线性过程不是一个现实的过程。这只是减少认知负荷的起点，直到您对DDD有信心为止。

如何调整流程？

此过程可以通过多种方式进行自定义。在实际项目中，您将根据获得或需要获得的新见解在所有8个步骤之间切换。

以下是决定何时更改顺序或在步骤之间切换的几个原因。

从协作建模开始

如果你想让你的整个团队立即协作，对他们熟悉的领域进行建模可能比谈论他们不太熟悉的商业模式和战略更舒服。

从评估 IT 环境开始

在展望业务愿景并深入研究该领域之前，最好先可视化现有架构。从第5步开始，制定您的战略投资组合，看看您将面临的主要限制是什么。

确认体系结构和团队边界之前的代码

在某些项目中，尽早开始编写代码是有意义的。也许您需要交付MVP，或者域非常复杂，因此在考虑体系结构之前，必须在代码中创建模型。

重复步骤 2（发现）- 6（组织），然后再转到 7（定义）

在深入研究单个有界上下文的定义之前，对域进行多次建模并寻找不同的方法来将系统分解为子域和团队可能是有益的。

在设计上下文之前组织团队

对于大量的项目，我们需要考虑组织约束。如果是这种情况，您应该考虑在设计永远无法实现的体系结构之前确定可能的团队结构。

混合定义和编码

步骤 7（定义）和 8（代码）可以同时发生。当您对有界上下文进行编码时，可能会发生这种情况，并且您从编写代码中获得的见解会使您更改高级设计。

过程

建模过程由8个步骤组成，下面介绍这些步骤。

在设计社会技术架构的典型阶段的背景下，一个很好的演讲概述了这个过程，是爱德华多·达席尔瓦（Eduardo da Silva）的“社会技术架构：共同设计技术和组织架构以最大化影响”。Eduardo将流程的活动及其8个步骤分为四个不同的阶段，即：

  1. 对齐和理解
  2. 战略架构
  3. 战略与组织设计
  4. 战术架构。

理解

将我们的重点与组织的业务模式、用户需求以及短期、中期和长期目标保持一致。

我们做出的有关体系结构、代码或组织的每项决策都会对业务和用户产生影响。为了最有效地设计、构建和发展软件系统，我们的决策需要创造最佳的业务影响，这只有在我们与业务目标保持一致并支持用户当前和潜在的未来需求时才能实现。

设计不当的架构和/或边界可能会产生负面影响，甚至无法实现这些目标。

作为起点，我们推荐业务模型画布从业务角度看，用户故事映射用于理解用户有利位置。

The Business Model Canvas

让谁参与进来

  • 设计、构建、测试软件的人员
  • 具有领域知识的人
  • 了解产品和业务战略的人员
  • 真正的最终用户，而不仅仅是他们在组织中的代表

发现

以可视化和协作方式发现域名。

这是DDD最关键的方面。不能跳过发现。如果您的整个团队没有建立对该领域的良好理解，那么所有软件决策都将被误导。

在整个团队中传播领域知识将创造一种共同的理解。它使开发人员能够构建与域一致的软件系统，该系统可以更灵活地纳入未来的业务变化。

确保将领域知识传播到整个团队，使其成员能够为改进产品提供想法。

发现是连续的

使用DDD成功的团队正在频繁地练习发现技术。关于这个领域，总有更多需要了解的地方。

当第一次尝试发现时，对EventStorming等技术有经验的协调人可以帮助团队看到发现的真正好处，而不仅仅是肤浅的层面。

作为起点，我们建议使用 EventStorming。

EventStorming

工具

让谁参与进来

  • 设计、构建、测试软件的人员
  • 具有领域知识的人
  • 了解产品和业务战略的人员
  • 了解客户需求和问题的人
  • 真正的最终用户

分解

将域分解为子域 - 域的松散耦合部分。

出于以下几个关键原因，我们将大型问题域分解为子域：

  • 减少认知负荷，以便我们可以独立推理部分领域，
  • 赋予开发团队自主权，以便他们可以在解决方案的不同部分工作，
  • 识别该领域的松散耦合和高内聚性，这延续到我们的软件架构和团队结构中。

作为起点，我们建议您将事件风暴划分为子域和上下文地图。

Sub-domains on an EventStorm 图片来源：Alberto Brandolini

工具

让谁参与进来

  • 设计、构建、测试软件的人员
  • 具有领域知识的人

连接

将子域连接到松散耦合的体系结构中，该体系结构可满足端到端业务用例。

不仅要将一个大的领域分解成部分，还要仔细设计这些部分之间的相互作用，以最大限度地减少不必要的耦合和复杂性。有必要通过应用具体的用例来揭示隐藏的复杂性来挑战初始设计。

作为起点，我们建议使用域消息流建模。

Domain Message Flow Modelling

工具

让谁参与进来

  • 设计、构建、测试软件的人员
  • 具有领域知识的人

策划

战略性地绘制出您的子领域，以确定核心领域：领域中具有最大业务差异化或战略意义潜力的部分。

时间和资源是有限的，因此了解要关注的领域的哪些部分对于提供最佳的业务影响至关重要。

通过分析您的核心领域是什么，您将更好地了解构建系统的每个部分需要多少质量和严谨性，并且您将能够做出受过高等教育的构建与购买或外包决策。

作为起点，我们推荐核心域图表。

Core Domain Charts

工具/资源

让谁参与进来

  • 了解产品和业务战略的人员
  • 设计、构建、测试软件的人员
  • 具有领域知识的人

组织

组织经过优化的自主团队，以实现快速流动，并与上下文边界保持一致。

团队需要组织起来，以拥有自主性，明确的目标和目的感。为了做到这一点，我们需要考虑组织约束，以便团队组织自己以实现快速流动。

团队自组织

组织不是对团队做的事情，而是团队应该参与定义其边界，互动和责任的过程。

像Red Gate Software这样的一些公司授权并信任他们的团队来充分组织自己。

如果我们使团队与上下文边界保持一致，我们可以优化人们相互协作的方式。为了调整团队规模，我们需要考虑可用的人才、认知负荷、沟通开销和总线因素。

作为起点，我们建议使用上下文映射可视化社会技术架构。最重要的模式的简要概述可以在上下文映射GitHub项目下找到。

Context Map 图片来源：Michael Plöd

工具

让谁参与进来

  • 设计、构建、测试软件的人员
  • 具有领域知识的人
  • 了解产品和业务战略的人员

定义

定义每个有界上下文的角色和职责。

在致力于设计之前，请对可能对整体设计产生重大影响的选择做出明确的决定。尽早进行这些对话，同时仍然很容易改变主意并探索替代模型。

以协作和可视化的方式进行设计，并开始考虑技术限制，以便您可以发现限制或机会。

作为起点，我们建议使用有界上下文画布。

Bounded Context Canvas

工具

让谁参与进来

  • 设计、构建、测试软件的人员
  • 具有领域知识的人
  • 对产品负责的人员

法典

对域模型进行编码。

通过将代码与域对齐，可以在域更改时更轻松地更改代码。通过与专家协作对问题空间进行建模，开发人员有机会了解该领域并最大限度地减少误解。

作为起点，我们建议使用聚合设计画布。

Aggregate Design Canvas

工具

让谁参与进来

  • 设计、构建、测试软件的人员

DDD 启动器建模过程与漩涡池过程的关系

你们中的一些人可能已经注意到与埃里克·埃文斯（Eric Evans）的《漩涡过程》（Whirlpool Process）有一些相似之处。事实上，两者都是指南，而不是僵化的最佳实践。它们也是连续的和迭代的。 但是，DDD入门建模过程涵盖的不仅仅是惠而浦过程，旨在构建社会技术架构。 下图显示了这两个过程之间可能存在的重叠。

WhirlpoolVSStarter

毋庸置疑，Eric Evan的Whirlpool过程在今天仍然完全相关，并为人们提供了有关如何探索模型的非常有价值的见解和指导。