活动回顾 | 领域驱动设计实战工作坊之金融科技专场

期待已久的【领域驱动设计实战工作坊——金融科技专场】终于在上周末落下了帷幕。一起来瞧瞧过去的这两天，我们完成了怎样的一次头脑风暴和思想碰撞！

整个工作坊以肖然老师的“统一语言”开场，逐步细化，直到领域驱动设计（DDD）元模型的轮廓完整展现。元模型让学员们可以对领域驱动设计（DDD）最本质的部分建立初步的认识。也是学员深入掌握领域驱动设计（DDD）的内功心法。

系统存在的价值某种程度上就是系统体现出的业务价值，在展开领域建模之前，对齐系统的业务价值是最重要的工作，王威老师借助干系人分析与电梯演讲等一系列方法，让不同的小组为【供应链金融主题案例】定位关键用户与核心业务价值，不同的小组在同一个大的业务背景下，识别出了核心业务价值，也为待构建的系统选择了不同的发力方向。在这个环节中大家也充份意识到，虽然大家在同一个业务背景下，核心业务价值定位不同，商业模式及业务战略也会有很大差异，这一方面在价值定位之后如果想调整几乎是不可能的。

完成价值定位之后，进入整个工作坊的重头戏——事件风暴（Event Storming），通过识别整个问题域的关键领域事件来绘制问题域蓝图。在问题域中，整个小组以头脑风暴的形式，一起发散发现问题域中业务关心的事件。然后在白板上共同讨论达到团队统一的、有时间线的事件流。在这个过程中，业务与技术人员充分讨论，形成以业务为中心的统一语言共识；同时在识别领域事件的过程中也要体现出如何实现系统核心业务价值；高质量的领域事件识别，可以做到通过讲述领域事件来体现商业价值，不需要特别解释。

有了问题域蓝图及明确的业务价值定位，接下来要将已经识别出的领域事件进行子域划分，找到整个业务蓝图中的核心问题域，叫做核心子域，这部分是需要领域建模的部分，也是能体现出系统核心价值的部分。确定核心子域后，面向核心子域进行第二阶段的事件风暴，细化核心子域中的所有领域事件，这些领域事件将做为后续服务设计与领域模型的基础输入。在细化过程中大家需要注意的是：

1. 描述领域事件，用业务有价值的名词与动词，避免用XXX已执行，像“执行”这样过于抽象的动词 


2. 领域事件要有完整的生命周期，有订单已创建，也应该有订单已完成 


业务蓝图有了，核心子域也划分出来了，接下来要完善核心子域的领域事件的实际业务场景，这个环节被称为命令风暴(或决策风暴)，以下统称决策，小组一起找到触发每个事件的决策，这里要注意的是决策不是ACTION。之间的区别在于：Decision —> 审核通过 Action —> 审核。每个事件都能够找到产生这个事件的源，包括：决策，时间，外部系统，其它事件。对于识别出来的决策，一定是我们系统中某一个actor触发的，为命令/决策找 actor将有益于确定领域事件的职责归属，辅助设计出单一职责的服务。同时在有了actor之后每个领域事件所对应的场景也就更加完善了。这里需要说明的是，如果一个事件是由另一个领域事件触发时，事件之间是通过策略(policy)触发的。

有的时候，如果想为UX设计提供支持时，也可以在Actor与决策后，可以在Actor与决策之间识别出帮助Actor做出决策所需要的信息，称之为读模型。这一步并不是必需的。

有了Actor与Decision后, 事件的场景更加生动，上下文也更完备了，接下来要在决策和事件中加业务主体(业务概念)，识别事件产生事件中间的实体。例如：在订单已创建领域事件与下单决策之间抽象的业务主体有可能是订单。这一部分有两个线索可以用：

1. 找决策与事件中的名词，并通过上下文场景验证业务概念的合理性 


2. 如果命令与决策之间出现了多个名字，通过ACTOR辅助判断场景归属 


如果进展顺利会得到少于领域事件的业务主体个数，一般情况下，一个业务主体可以接受多个决策，产生多个命令。在这个环节中得到的业务主体，一般称为问题域聚合，Event Storming的创始人Allbotto也喜欢称之为状态机。

到这里整个工作坊的再一次进入总结与升华阶段，肖然老师根据同学们的建模结果进一步总结出事件风暴的元模型，帮助学员更好的理解整个事件风暴体系：

接下来进入服务设计环节，基于DDD的方法论实践，服务设计是从识别限界上下文开始的，基于已有的问题域聚合进行划分，主划分思路如下：

1. 将业务能力分组，将业务能力相似的问题域聚合放到一个限界上下文中。 


2. 打开问题域聚合，发现问题域中有二义性的部分，将其分解成多个聚合，划分到不同的限界上下文中。 


3. 根据组织结构与团队结构，将不同团队所负责的业务能力放到不同的限界上下文中。

4. 考虑技术约束，包括：技术异构与语言异构，非功能需求，技术限制等。 


通过从不同维度分解问题域的业务能力，将设计好的聚合分配到了多个不同的限界上下文中，每个限界上下文承担起整个系统中的一部分业务能力，业务价值是通过多个业务能力相互协作得到的，所以接下来我们要确定不同限界下文的关系。上下文之间的关系有一系列模式可以参考，如：反腐层，共享内核，生产者/消费者，共享主机，尊奉者等等。根据不同限界上下文的情况选择即可。

完成了服务设计的过程之后，为了更好的帮助团队落地，整个工作坊除了服务设计还提供了领域模型细化，API设计，分层架构设计等主题。领域模型细化，会以问题域聚合为基础进行模型细化，重点考虑实体与值对象为代码实现提供进一步的设计支撑。API设计是以REST API为参考，从三个不同的角度设计出REST成熟度为级别二的，面向资源的API。

工作坊的最后一个主题是分层架构，当我们设计出领域模型后，如何让它落地是我们接下来的要考虑的问题，传统分层架构更多的关注了将几个主要的关注点分离，仅做到这点是不足以支持领域模型落地的，为了更好的落地领域建模成果，DDD将传统的分层架构做了演进，让其分离技术复杂度与业务复杂度，将业务逻辑也分成了领域逻辑与应用逻辑，构建了以领域为中心的分层主导思想，也有相应的架构模式演化出来，包括：六边型架构，洋葱架构，整洁架构等。

经过上述一系列的实践之后，开发人员可以基于模型驱动在分层架构写具体代码。在这里需要强调的是，领域模型是面向问题域设计的解决方案，随着需求的持续演进，问题域也会随着发生变化，领域模型的持续有效，要基于问题域的演进而演进，应保持与领域专家持续迭代沟通探索领域模型，使用面向领域模型的重构，柔性设计等方法，才能持续发挥出领域模型的最大价值。以终为始，让领域模型真正成为应对复杂问题之道也是目标。

活 动 预 告

云时代 l 领域驱动设计中国峰会2018

软件设计的旗帜性峰