下文源于我12月21日在TGO成都分会E家宴上的分享。我本人也是领域驱动设计的初学者，DDD（Domain-driven-design）是一种思考问题的方式和解决问题的方法，要想深入理解还需要反复的思考和练习。
正文：
今天我分享的主题是《领域驱动设计之事件风暴》。当我每次去思考把一个话题讲清楚的时候，习惯于从Why（为什么），How（如何做），What（是什么）的角度展开。坦白地说，短时间甚至没可能把领域驱动设计中的Why讲清楚。所以构思今天这个分享的时候， 我反复斟酌，希望通过一条主线和大家一起走进领域驱动设计的世界。
我们还是从“为什么”开始：软件系统设计面临的挑战。
我们都理解软件开发的不确定性贯穿了整个软件工程的生命周期，很多时候我们希望通过敏捷的方式来应对不确定性，在软件工程里面这种不确定性包括进度、需求、成本等等。然而本就没有所谓的“银弹”：没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性。
那么如何应对业务的复杂性呢？在这个背景下，领域驱动设计横空出世。
领域驱动设计是一种处理高度复杂领域的设计思想，试图通过分离技术实现的复杂性，围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解、难以演化等问题。团队应用它可以成功地开发复杂业务软件系统，使系统在增大时仍然保持敏捷。
DDD有几个核心思想：
领域驱动设计包括两个阶段：
Eric Evans在《领域驱动设计》中建议开发一个共享域模型，作为领域专家和IT之间的桥梁，它以无处不在的语言编写并由应用程序代码实现。近年来，为这些活动建立了两种研讨会的形式。
这两种形式的研讨会都有助于为IT专业人员提供对域的深入洞察和开发域的通用可视化模型。
下面我来以一个具体的电商场景为例，分享事件风暴工作坊是如何开展的。
事件风暴工作坊
准备工作
事件风暴
设计业务场景：根据产品愿景与价值定位，设计关键场景，找出起点与终点。
找出领域事件
事件排序
命令风暴
命令是产生事件的领域行为或领域活动，它可以是:
找出命令
寻找聚合
找出领域名词
通过分析前一步产生的领域事件寻找领域名词，规则如下：
确定领域聚合
在确定领域聚合的时候，我们可以这样思考：它是否可以被独立访问，如果可以被独立访问就是一个聚合，如果不能被独立访问就应该属于它依赖的聚合。
最后留下聚合即时贴：命令在左面，事件在右面。
未完待续
在这个电商的场景中，如果我们聚焦于订单的上下文，可以拆分出三个领域事件，分别是：订单已创建、订单已取消和订单已支付。下一步我们要做的就是用代码来实现该领域模型。
最后给大家推荐两本非常经典的软件管理学著作：《人月神话》和《人件》。这两本书都不约而同地提到了软件工程的核心思想：软件工程核心实质是社会工程，优秀团队的竞争力来源于互相的信任及良好的沟通。让我们共勉，谢谢大家！
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
