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

使用此过程将引导您完成设计具有 DDD 思维的软件系统的每一个基本步骤，这样您就可以专注于业务挑战，而不是同时学习 DDD 而不知所措。

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

这个过程是为初学者。这不是一个线性的步骤序列，你应该标准化作为一个最佳实践。领域驱动设计是一个进化设计过程，需要在知识和设计的各个方面进行连续迭代。

image-20210924182707372

导航：

流程

建模过程由以下介绍的 8 个步骤组成。

爱德华多·达席尔瓦（Eduardo da Silva）在"社会技术建筑：共同设计技术和组织架构以最大限度地发挥影响力"这一良好论述中概述了社会技术建筑设计典型阶段的过程。爱德华多将这一进程的活动及其8个步骤分为四个不同的阶段，即：

  1. 对齐 = 理解
  2. 战略架构
  3. 策略与公司设计
  4. 战术架构。

理解

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

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

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

作为起点，我们推荐商业模型画布为业务渗透，用户故事映射了解用户的优势点。

image-20210924182650081

工具

涉及谁

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

发现

以视觉和协作方式发现域。

这是 DDD 最关键的方面。你不能跳过发现。如果您的整个团队没有很好地了解该域，则所有软件决策都将被误导。

通过整个团队传播域知识将创建共享的理解。它使开发人员能够构建与域对齐的软件系统，该系统可以更灵活地整合未来的业务变化。

确保域知识在整个团队中传播，使其成员能够为改进产品献计献策。

发现是连续的

使用 DDD 取得成功的团队正在频繁练习发现技术。关于域名，总有更多的要了解的。

当第一次尝试发现时，具有事件风暴等技术经验的促进者可以帮助团队看到发现超越表面层面的真正好处。

我们强烈鼓励您查看视觉协作工具。

作为起点，我们建议事件风暴。

image-20210924182735066

工具

涉及谁

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

分解

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

我们将一个大问题域分解为子域有几个关键原因：

  • 减少认知负荷，以便我们可以独立推理域的某些部分，
  • 给予开发团队自主权，以便他们能够处理解决方案的单独部分，
  • 识别延续到我们的软件架构和团队结构的领域中的松散耦合和高凝聚力。

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

image-20210924182751417

工具

涉及谁

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

连接

将子域连接到一个松散耦合的架构中，满足端到端业务使用案例。

不仅必须将大域分解成零件，而且必须仔细设计这些部分之间的相互作用，以尽量减少不必要的耦合和复杂性。有必要通过应用具体的用例来发现隐藏的复杂性，从而挑战初始设计。

作为起点，我们推荐域消息流建模。

image-20210924182829438

工具

涉及谁

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

策划

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

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

通过分析您的核心域名，您将更好地了解构建系统每个部分所需的质量和严格程度，并且您将能够做出高学历构建与购买与外包决策。

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

image-20210924182847915

工具/资源

涉及谁

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

组织

组织自主团队，这些团队进行优化，实现快速流动并符合上下文边界。

团队需要组织起来，才能有自主性、明确的目标和目标感。为了做到这一点，我们需要考虑到组织限制，以便团队组织起来快速流动。

团队自组织

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

一些公司，如红门软件授权和信任他们的团队充分组织自己。

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

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

image-20210924182915230

工具

涉及谁

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

定义

定义每个边界上下文的角色和责任。

在进行设计之前，要明确决定对整体设计有重大影响的选择。尽早进行这些对话，同时仍然很容易改变主意并探索其他模式。

协作和视觉设计，并开始考虑技术限制，以便您能够发现限制或机会。

作为起点，我们推荐边界上下文画布。

image-20210924183116696

工具

涉及谁

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

法典

对域模型进行编码。

将代码与域对齐使域更改代码更加容易。通过与专家合作建模问题空间，开发人员有机会了解域并最大限度地减少误解。

作为起点，我们推荐聚合设计画布。

image-20210924183130979

工具

涉及谁

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