ddd-crew/ddd-starter-modelling-process:DDD设计入门建模流程


如果您是DDD的新手,并且不确定从哪里开始,则此流程为您提供了逐步指南,帮助学习和实际应用域驱动设计的各个方面:从围绕组织的业务模型定位到编码域模型。
使用此流程将指导您完成设计具有DDD思维方式的软件系统的每个基本步骤,因此您可以专注于业务挑战,而不会因同时学习DDD而感到不知所措。
完成该过程的几次迭代后,您将具有基础的DDD理论和实践经验,可以更深入地研究DDD。然后,您将能够适应和改进流程,以适应任何情况下的需求。在实际的项目中,您经常会在这些步骤之间来回跳动。
注意:
此过程适用于初学者。您不应将步骤标准化为最佳实践。域驱动设计是一个进化的设计过程,需要在知识和设计的各个方面进行连续迭代。


 图中步骤如下:

  1. 对齐:业务模型对齐需求
  2. 发现:对领域实现可视化和协作
  3. 解耦:将领域分为子域
  4. 连接:将子域形成为一种松耦合架构
  5. 战略:专攻业务差异化的核心子域
  6. 组织:按照有界上下文组织团队
  7. 定义:定义每个有界上下文的角色和职责
  8. 编码:使用战术模式实现有界上下文


何时使用DDD Starter建模过程?
如果您不熟悉DDD,或者不确定从哪里开始,那么此过程可以减轻您的认知负担。它将指导您完成以下方案,以及其他方案:

  • 启动新项目:在一个新项目开始时,您需要考虑的事情可能会令人不知所措。此过程的一两次迭代可以帮助您奠定基础。
  • 开始旧项目迁移:在开始对遗留系统进行现代化之前,此过程的一些迭代可以帮助您发现为目标体系结构创建愿景所需的基本信息。
  • 启动主要工作计划:当开始一项新计划涉及许多团队的重大投资时,必须涵盖该过程中的8个步骤。此过程可以指导您完成前几次迭代。
  • 探索您的领域以获得新的学习机会:软件开发是一个学习过程。您可以随时应用DDD Starter建模流程来发现新见解,发现新机会或在团队中简单地共享知识。
  • 评估项目的当前状态:此过程可以作为评估当前系统与域和业务模型的协调程度的基础。
  • 重组团队:松散耦合的体系结构使团队可以并行工作而不会受到阻碍。松散耦合的体系结构还必须与域中的耦合对齐。此过程将帮助您设计软件体系结构以及与您的域保持一致的团队结构。
  • 练习或学习DDD:当您是DDD的新手并且想要练习时,或者您要教别人建模域的不同方面时,此过程非常理想。重要的是要传达这一线性过程不是现实的过程。这只是减少认知负担的起点,直到您对DDD充满信心为止。

流程详细
此过程由以下8个步骤组成:
1.对齐
使我们的重点与组织的业务模式,用户的需求以及短期,中期和长期目标保持一致。
我们对体系结构,代码或组织所做的每个决定都会带来业务后果。为了最有效地设计,构建和发展软件系统,我们的决策需要创造最佳的业务影响,只有当我们与业务目标保持一致时才能实现。
设计不良的体系结构和/或边界可能产生负面影响,甚至使实现这些目标变得不可能。
首先,我们建议使用“业务模型画布”

工具类


谁参与
  • 设计,构建,测试软件的人
  • 有领域知识的人
  • 了解产品和业务策略的人

2.发现
通过视觉和协作发现域。这是DDD的最关键方面。您不能跳过发现。如果您的整个团队对领域没有很好的了解,那么所有软件决策都会被误导。通过整个团队传播领域知识将建立共同的理解。它使开发人员能够构建与该领域相对应的软件系统,从而可以更加灵活地合并未来的业务变更。确保领域知识遍及整个团队,使成员能够为改进产品做出贡献。
发现是连续的,成功使用DDD的团队经常练习发现技术。总是有更多有关该域的知识。首次尝试发现时,具有EventStorming等技术经验的协调员可以帮助团队从浅层次上发现发现的真正好处。
我们强烈建议您查看Visual Collaboration Tools
作为起点,我们建议使用EventStorming

工具类


谁参与
  • 设计,构建,测试软件的人
  • 有领域知识的人
  • 了解产品和业务策略的人
  • 了解客户需求和问题的人
  • 真正的最终用户

3.分解
将领域分解为子域-域的松散耦合部分。
出于以下几个关键原因,我们将大问题域分解为子域:

  • 减少了认知负担,因此我们可以独立地推理领域的各个部分,
  • 给开发团队自治权,以便他们可以在解决方案的各个部分工作,
  • 识别域中的松散耦合和高内聚性,这会延续到我们的软件架构和团队结构中。

首先,我们建议将事件风暴划分为子域和上下文映射

工具类


谁参与
  • 设计,构建,测试软件的人
  • 有领域知识的人

4.连接
将子域连接到一个松散耦合的体系结构中,该体系结构可以满足端到端业务用例。
必须不仅将大的区域分解成多个部分,而且还必须仔细设计这些部分之间的交互,以最大程度地减少不必要的耦合和复杂性。有必要通过应用具体用例来揭露隐藏的复杂性来挑战初始设计。
首先,我们建议您使用域消息流建模

工具类


谁参与
  • 设计,构建,测试软件的人
  • 有领域知识的人

5.制定战略
从战略上规划您的子域,以识别核心域:该域中具有最大业务分化潜力或战略意义的部分。
时间和资源是有限的,因此了解域的重点是提供最佳业务影响至关重要。
通过分析核心领域是什么,您将更好地了解系统各部分的质量和严格程度,并且能够做出受过良好教育的构建,购买还是外包决策。
首先,我们建议使用Core Domain Charts

工具类


谁参与
  • 了解产品和业务策略的人
  • 设计,构建,测试软件的人
  • 有领域知识的人

6.组织
组织针对快速流程进行优化并与上下文边界保持一致的自治团队。
需要组织团队以具有自主权,明确的目标和目标感。为此,我们需要考虑组织上的限制,以便团队进行自我组织以实现快速流动。
团队自我组织:组织不是对团队进行的工作,而是团队应参与定义其边界,相互作用和职责的过程。
诸如Red Gate Software之类的一些公司授权并信任他们的团队以充分组织自己
如果使团队与上下文边界保持一致,我们可以优化人们之间的协作方式。为了确定团队的规模,我们需要考虑可用的人才,认知负担,沟通开销和总线因素。
首先,我们建议使用Context Maps可视化社会技术架构。
图片来源:MichaelPlöd
工具类


谁参与
  • 设计,构建,测试软件的人
  • 有领域知识的人
  • 了解产品和业务策略的人

7.定义
定义每个有限上下文的角色和职责。
在进行设计之前,请对选择做出明确的决定,这些选择可能会对整体设计产生重大影响。在仍然很容易改变主意并探索替代模型的同时,尽早进行这些对话。
进行协作和可视化设计,并开始考虑技术限制,以便您可以发现制约因素或机遇。
首先,我们建议使用Bounded Context Canvas

工具类


谁参与
  • 设计,构建,测试软件的人
  • 有领域知识的人
  • 对产品负责的人

8.编码
编码实现领域模型。将代码与域对齐可使域更改时更轻松地更改代码。通过与专家协作对问题空间进行建模,开发人员有机会了解该领域并最大程度地减少误解。
首先,我们建议使用“ 聚合设计画布”

工具类


谁参与
  • 设计,构建,测试软件的人

详细点击标题见Github项目