我正在参与掘金创作者训练营第4期，点击了解活动详情，一起学习吧！
答案
先说答案吧，DDD 绝对适用于 Scrum 开发。接下来我们再看看，为什么会有这种疑问？结论是如何得出来的？
什么是DDD
DDD（领域驱动设计）的概念是2003年Eric Evans在《Domain-Driven Design: Tackling Complexity in the Heart of Software》一书中提出来的，对这本书感兴趣的同学可以看下我的读书笔记，同时建议大家购买正版。如果用两句话来总结这本书的话，大概就是：
- 软件的复杂性主要来自于领域的复杂性
- 基于模型的设计可以帮助解决领域复杂性问题
书中介绍了很多针对领域建模的方法，概括来说可以分为战术设计和战略设计。战术设计主要介绍了模型的基本构造块，例如ENTITY，VALUE OBJECT，AGGREGATE，REPOSITORY等等。而战略设计主要介绍了如何处理模型和模型之间的关系，包括BOUNDED CONTEXT，CONTEXT MAP等模式。
什么是Scrum
Scrum是一种敏捷开发框架，定义一组用于迭代开发的活动骨架以及参与这些活动的角色。Scrum中的主要角色包括：
- Scrum Master是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍；
- 产品负责人，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资回报率负责；
- 开发团队，一个跨职能的小团队，人数5-9人，团队拥有交付可用软件需要的各种技能。
主要的活动都是围绕Sprint（冲刺）展开的，包括：
- Sprint Planning：计划会议，团队决定在下一次迭代中能完成多少Product Backlog
- Daily Scrum：每日站立会议，团队成员轮流回答以下问题：
- 昨天你完成了那些工作？
- 今天你打算做什么？
- 完成你的目标是否存在什么障碍？
- Sprint Review：评审会议
- Sprint Retrospective：为了进行持续过程改进，在Sprint结束后会进行回顾会议
下图很形象地展示了Scrum中的主要活动流程和参与的角色。
为什么会产生疑问
Scrum 一词源于英式橄榄球运动，是指双方球员围在一起，列阵争球。基于Scrum的开发团队，跟英式橄榄球队之间有很多相似之处，例如英式橄榄球队中的球员分为进攻、防守和特别队员三种职能，三者各有优势又互相配合，其中特别队员进可攻退可守，可以随时转换为其他两种角色。而在Scrum团队中，也只有三个角色，分别是产品负责人(PO)、Scrum Master和开发团队，其中开发团队成员之间的工作重合度高，可以相互替换。另外英式橄榄球比赛的时间短，没有护具，跑动灵活，而相应的，Scrum开发有着迭代周期短、增量计划灵活的特点，与橄榄球比赛非常契合。
Scrum关注的是敏捷开发团队成员间的协作配合，团队的运作方式。而DDD关注的是从业务->模型->代码的设计过程，很容易让人联想到瀑布开发流程中的需求->软件->编码，而这种工作方式又跟强调敏捷开发的Scrum格格不入。如果只停留在表面的理解，很容易产生如题所示的疑问：DDD 适用于 Scrum 开发吗？
模型探索漩涡
DD的作者Eric早就回答了这个问题。关于在敏捷环境下如何构建模型，他打了一个比喻：模型探索漩涡!
那么如何根据这样一个模型探索漩涡，进行敏捷开发呢。接下来我们将结合EventStorming（事件风暴）和Example Mapping（示例映射）来具体说明。
Harvest & Document
我们从收获和记录当前状态开始模型探索。主要的目标是：收集参考场景，捕捉模型的片段，然后将大部分的想法抛之脑后。EventStorming可以作为这个阶段的起点。EventStorming是我最喜欢使用的工具之一，在对复杂的商业领域进行合作开发时，它可以帮助你在短短的几个小时内，收获大量的业务知识。要想在这个阶段取得成功，必须邀请合适的领域专家参与。
Workshop
为了开展Workshop，需要找到足够的空间（比如一个有8米长的墙的房间），还需要一个白板。现在我们可以通过EventStorm来开始捕捉当前状态。我们给参与者提供橙色的贴纸和一支记号笔。我们要求他们写下领域事件（这是后来Eric在参考书中加入的一个模式）。简而言之，领域事件是在领域中发生的与业务相关的事情。我们要捕捉当前状态的领域事件，并按时间顺序把它们贴在墙上。
Tell a story
当每个领域专家都写下他们的领域事件之后，就可以讲一个故事了。让与会者通过讲故事来确认时间线，并且删除重复的事件。通常人们在判断一个领域事件是相同或者不同的时候，针对领域知识会出现不同意见。用鲜艳的彩色贴纸标记热点。
让隐性的东西显性化
EventStorming的核心是：我们只讨论显性和可见的东西。在领域事件和热点中，我们能捕捉到的知识实在是太多了；我们可以用其他颜色捕捉更多类型的知识。标准的EventStorming颜色是：
- 蓝色：行动/命令
- 粉色：(外部)系统
- 紫色：政策/实际业务约束
- 绿色：信息
基本的流程会是上面这样的，这里的关键点是房间里的每个人都认同。如果我们不知道从哪里下手，就试着按照这个流程来。记住要让隐性的东西，显性化。
偏差盲点
现在，故事已经完成了，我们想引入示例映射。大多数情况下，人们现在会认为引入另一个工具是浪费。故事已经可视化了，但我们得到了完整的故事吗？问题是，每个人都会受到认知偏差的影响，特别是当我们遇到信息过载时。
我们会注意到已经在记忆中根深蒂固的或经常重复的事情；这被称为背景效应和注意偏差。我们也会被那些可证实自己现有信念的细节所吸引；这被称为观察者效应。特别是偏差盲点，在我们探索领域的过程中，更容易注意到别人的缺陷，而忽略自己的缺陷。
为了对抗这些偏见，我们需要使用不同的观点和工具。示例映射可以帮助我们，因为它更注重于具体的例子。在绿色贴纸上写下示例，展开头脑风暴。换位思考，看看这些例子对当前EventStorm的影响在哪里。如果它是当前系统中的一个空白，用热点标记它，让它变得明确！现在房间里的人应该对对当前状态有了足够的认识。我们已经可以看到有边界的上下文出现了，或者看到哪些部分相互纠缠，没有明确的边界。
SCENARIO
现在我们已经获得了系统当前状态的知识，对于接下来要开发的内容也需要做同样的事情。我们可以创建一个新的建模空间，再次进行EventStorming。
演练和重新关注困难的部分
一旦我们有了所有的事件，我们要做的是和上次一样，对事件进行演练，强制执行时间线并删除重复的领域事件。另外还要做的是重新关注困难的部分，找到复杂性所在。我们用黄色标签表示一致的业务规则，它总是在一个领域事件的前面。
我们要首先寻找一致的和最终一致的业务规则（黄色和紫色），并关注这些部分。通过添加其他颜色的贴纸使故事保持一致。专注于所使用的语言；必须找到那些模棱两可的词汇。另外，开始加入Actor，明确由谁负责故事的哪一部分。所有这些信息结合起来，就是定义一个有边界的上下文所需的全部内容。
示例映射
再次使用示例映射。从头脑风暴开始，在EventStorm旁边写下例子。只是这一次我们还将在示例映射中更进一步，通过业务规则将示例结构化为垂直的列。把业务规则写在例子上方的蓝色贴纸上。重要的是每一列只有一条业务规则。只有一条业务规则意味着特定的例子可以在不同的业务规则下多次出现。
业务规则将与你的EventStorm上的业务规则匹配，这是你也可能会发现新业务规则。这两个工具的目标是分享知识和探索复杂的业务领域，所以不要花费过多精力使两者完全一致。
建模（MODEL）和编码探查（CODE PROBE）
有了我们新需要的知识，现在是开始建模的时候了。我们首先将探索不同的模型，看看这些模型在EventStorm和你的示例映射上的例子中会有什么表现。试着找到至少三个模型，并快速迭代它们。一旦你最终得到一个可行的模型，我们现在就可以对我们的示例映射进行分解，讨论哪些业务规则是最重要的，然后正式确定示例。
有了可行的模型和正式的示例，我们现在可以开始编码了。因为我们知道系统需要做什么，基于正式的示例，很容易使用测试驱动开发来编写模型的代码原型。这样我们就可以不断地完善我们的语言，挑战我们的模型。
总结
本文解答了DDD 是否适用于 Scrum 开发，并结合EventStorming和ExampleMapping，以适合敏捷开发的迭代方式探索领域模型。