Github
文档领域驱动设计入门建模流程
这个流程为您提供了学习和实际应用领域驱动设计(DDD)各个方面的分步指南 - 从围绕组织的业务模型到编写领域模型。
使用这个流程将指导您完成设计软件系统时DDD思维方式的每个基本步骤,这样您就可以专注于业务挑战,而不会被同时学习DDD而感到不知所措。
一旦您经历了这个流程的几次迭代,您将掌握DDD的基础理论和实践经验,能够深入学习DDD。然后您就能够根据任何情况下的需求来调整和改进这个流程。在实际项目中,您通常会在这些步骤之间来回跳转。
这个流程适合初学者。它不是一个应该标准化为最佳实践的线性步骤序列。领域驱动设计是一个演进式设计过程,需要在知识和设计的所有方面持续迭代。
导航:
何时使用DDD入门建模流程?
如果您是DDD新手或者不确定从哪里开始,这个流程可以减轻您的认知负担。它将指导您完成以下场景,可能还有其他场景:
启动一个全新项目
在新项目开始时,需要考虑的事情可能会让人不知所措。这个流程的一两次迭代可以帮助您奠定基础。
开始一个棕地迁移
在开始现代化您的遗留系统之前,这个流程的几次迭代可以帮助您发现创建目标架构愿景所需的基本信息。
启动一个大型工作计划
当启动一个新计划涉及多个团队的重大投资时,必须涵盖流程中的8个步骤。这个流程可以指导您完成前几次迭代。
探索您的领域寻找新的学习机会
软件开发是一个学习过程。您可以随时应用DDD入门建模流程来发现新的见解,识别新的机会,或者只是在团队中分享知识。
评估项目的当前状态
这个流程可以作为评估当前系统与领域和业务模型对齐程度的基础。
重组团队
松耦合的架构使团队能够并行工作而不会被阻塞。松耦合的架构还必须与领域中的耦合保持一致。这个流程将帮助您设计一个软件架构,以及与您的领域保持一致的团队结构。
练习或学习DDD
当您是DDD新手并想要练习,或者您想教别人领域建模的不同方面时,这个流程是理想的。重要的是要传达这个线性流程不是一个现实的流程。它只是一个起点,用于减少认知负担,直到您对DDD有信心为止。
如果您想自己尝试,SAP的同事创建了一个DDD Kata来教育团队如何在团队中应用DDD建模流程。基于一组需求,您可以尝试EventStorming、领域消息流、限界上下文画布和聚合画布如何协同工作并帮助您验证设计决策。
如何调整流程?
这个流程可以通过多种方式定制。在实际项目中,您会根据获得或需要获得的新见解在所有8个步骤之间切换。
以下是一些决定何时改变顺序或在步骤之间切换的理由。
从协作建模开始
如果您想让整个团队立即开始协作,建模他们熟悉的领域可能比讨论他们不太熟悉的业务模型和战略更舒服。
从评估IT景观开始
在关注业务愿景和深入领域之前,最好先可视化现有架构。从第5步开始,绘制战略组合图,看看您将面临的主要约束是什么。
在确认架构和团队边界之前编写代码
在某些项目中,更早开始编写代码是有意义的。也许您需要交付MVP,或者领域非常复杂,以至于在考虑架构之前需要在代码中创建模型。
在进入第7步(定义)之前重复第2步(发现)到第6步(组织)
在深入定义单个限界上下文之前,多次建模领域并寻找将系统分解为子域和团队的不同方法可能会有益。
在设计上下文之前组织团队
对于大量项目,我们需要考虑组织约束。如果是这种情况,您应该考虑在设计永远无法实现的架构之前确定可能的团队结构。
定义和编码相结合
第7步(定义)和第8步(编码)可以同时进行。当您在编写限界上下文时,从编写代码中获得的见解可能会让您改变高层设计。
流程
建模流程由8个步骤组成,下面介绍这些步骤。
在设计社会技术架构的典型阶段背景下,给出流程概述的一个好的演讲是Eduardo da Silva的"社会技术架构:协同设计技术和组织架构以最大化影响"。Eduardo将流程的活动及其8个步骤分为四个不同的阶段,即:
- 对齐与理解
- 战略架构
- 战略与组织设计
- 战术架构
理解
将我们的重点与组织的业务模型、用户需求以及短期、中期和长期目标保持一致。
我们对架构、代码或组织所做的每个决定都有业务和用户后果。为了最有效地设计、构建和发展软件系统,我们的决策需要创造最佳的业务影响,这只有在我们与业务目标保持一致,并支持用户当前和潜在的未来需求时才能实现。
设计不当的架构和/或边界可能会产生负面影响,甚至使实现这些目标变得不可能。
作为起点,我们推荐商业模式画布用于业务视角,用户故事地图用于理解用户视角。
工具
参与人员
- 设计、构建、测试软件的人员
- 拥有领域知识的人员
- 了解产品和业务战略的人员
- 真正的终端用户,而不仅仅是组织中的代表
发现
以可视化和协作的方式发现领域。
这是DDD最关键的方面。您不能跳过发现。如果您的整个团队没有建立对领域的良好理解,所有软件决策都将被误导。
将领域知识传播到整个团队将创建共同理解。它使开发人员能够构建与领域保持一致的软件系统,该系统可以更灵活地适应未来的业务变化。
确保领域知识在整个团队中传播,使其成员能够为改进产品贡献想法。
发现是持续的
成功应用DDD的团队经常练习发现技术。关于领域总是有更多需要学习的。
当第一次尝试发现时,一个在EventStorming等技术方面有经验的引导者可以帮助团队看到超出表面层面的真正好处。
我们强烈建议您查看可视化协作工具。
作为起点,我们推荐EventStorming。
工具
参与人员
- 设计、构建、测试软件的人员
- 拥有领域知识的人员
- 了解产品和业务战略的人员
- 了解客户需求和问题的人员
- 真正的终端用户
分解
将领域分解为子域 - 领域的松耦合部分。
我们将大型问题领域分解为子域有几个关键原因:
- 减少认知负担,以便我们可以独立地推理领域的各个部分,
- 给开发团队自主权,使他们可以在解决方案的不同部分工作,
- 识别领域中的松耦合和高内聚,这会延伸到我们的软件架构和团队结构。
作为起点,我们建议将事件风暴分解为子域和上下文地图。
*作者
工具
参与人员
- 设计、构建、测试软件的人员
- 拥有领域知识的人员
组织
组织自主团队，优化快速流程并与上下文边界保持一致。
团队需要组织起来，具备自主权、明确目标和目的感。为此，我们需要考虑组织约束，以便团队能够为快速流程自我组织。
团队自组织
组织不是对团队强加的东西，相反，团队应该参与定义自己的边界、互动和责任的过程。
一些公司如Red Gate Software赋予团队权力和信任，让他们完全自我组织。
如果我们将团队与上下文边界保持一致，我们可以优化人们之间的协作方式。为了适当调整团队规模，我们需要考虑可用人才、认知负荷、沟通开销和巴士因子。
作为起点，我们建议使用上下文映射来可视化社会技术架构。上下文映射 GitHub项目下可以找到最重要模式的简要概述。
来源: Michael Plöd
工具
参与人员
- 设计、构建、测试软件的人员
- 拥有领域知识的人员
- 了解产品和业务战略的人员
定义
定义每个限界上下文的角色和职责。
在承诺设计之前，明确可能对整体设计产生重大影响的选择决策。在仍然容易改变主意和探索替代模型时进行这些对话。
协作和可视化地进行设计，并开始考虑技术限制，以便发现约束或机会。
作为起点，我们推荐限界上下文画布。
工具
参与人员
- 设计、构建、测试软件的人员
- 拥有领域知识的人员
- 负责产品的人员
编码
编写领域模型的代码。
将代码与领域保持一致可以在领域变化时更容易地修改代码。通过与专家协作建模问题空间，开发人员有机会了解领域并最小化误解。
作为起点，我们推荐聚合设计画布。
工具
参与人员
- 设计、构建、测试软件的人员
DDD入门建模过程与涡流过程的关系
你们中的一些人可能注意到了与Eric Evans的涡流过程的一些相似之处。确实，两者都是指南而非严格的最佳实践。它们也都是持续的和迭代的。 但DDD入门建模过程覆盖的范围比涡流过程更广，旨在构建社会技术架构。 下图显示了两个过程之间可能的重叠。
不用说，Eric Evans的涡流过程在今天仍然完全相关，为人们提供了关于如何探索模型的高度宝贵的见解和指导。
贡献者
感谢所有现有和未来的贡献者以及以下为DDD入门建模过程做出贡献的个人：
贡献和反馈
领域驱动设计入门建模过程可供你自由使用。此外，欢迎你提供反馈和想法来改进该技术或创建替代版本。
如果你有问题，可以联系我们或开启一个Issue。
也欢迎你向我们发送包含案例研究的拉取请求。
本作品采用知识共享署名4.0国际许可协议进行许可。
