【Day 05】领域驱动设计的启动

观察的视角

我们要如何描述一个系统呢? 可以从不同的角度观察，好比瞎子摸象，你摸到甚麽部位，系统就像那一个局部，那就惨了，因此，建议不要局限於方法论，应该从各种视角去观察系统。

图一. 系统观察的视角(Viewpoints)

从上一篇知道 DFD 是从资料的流动与处理的角度观察系统的功能，Yourdon随後提出的个案是以事件为出发点描述系统，而领域驱动设计则是以事件加上实体(物件)角度出发，并且都加强了一些内容描述与整合，下面就来介绍相关的作法。

领域驱动设计以下简称DDD。

专案启动(Kick-off)

事件风暴(Event Storming)是高阶需求讨论的一种手法，由 Alberto Brandolini 於2013年提出，它举办的方式类似IBM的Joint application design(JAD)、SCRUM的冲刺计划会议(Sprint planning meeting)，是一种敏捷(Agile)的手法，想法是尽早让使用者参与专案，以免像传统的瀑布型开发方式，到了系统开发末期，一翻两瞪眼，使用者说『这不是我要的』，就前功尽弃了。一般作法就是邀请重要的利害关系人，包括领域专家、使用者、专案开发成员一起讨论愿景与需求，通常是先发散(Diverge)再收敛(Converge)，先由所有人脑力激荡，天马行空的提出各种想法，然後，再由主持人将想法合并归类，事件风暴的作法是以事件为导向，整理出事件的触发者、包含的实体及相关的讯息，包括参与的角色与权限等。

相关的手法可参考JAD、SCRUM，以下只列举几点说明：

1. 主持人至关重要，必须带动气氛，让大家勇於发表意见，但又要及时踩刹车，将想法合并归类，收敛後下结论，通常由业务经理或资深系统分析师担任。
2. 会议室的布置最好采圆桌或方形排列，象徵共同合作，切忌讲台式或面对面两列的排列，易造成一言堂或对立的气氛，SCRUM则建议使用大墙壁，大家都站着，可随意走动及小组讨论。
3. 善用便利贴，可方便移动归类。
4. 必须掌握时间，每次会议必须有结论，避免流於空谈。
5. 透过会议可逐步建立共通语言(Ubiquitous Language)、手法及共识，开发团队可整理出专门术语(Glossary)及其说明。

图二. SCRUM 白板，图片来源：dreamstim

产出

JAD订定九项关键步骤(Key Steps)，可以参考，每个步骤应该有哪些产出，不过，DDD在此阶段最重要的产出应该是：

1. 领域范围(Bounded Context)：有人直翻为【限界上下文】，界定整体系统的范围，并划分各个子系统的界线，如下图。
   
   图三. 领域范围(Bounded Context)，图片来源：Using domain analysis to model microservices

2. 接着对每个领域范围作进一步的分析，找出范围内所有的事件，并清楚定义触发者(Command)、Actor/User及处理流程，再从流程中提取实体(物件)，进而聚合(Aggegate)。

事件的触发者有很多种：

• 交易：例如销售、投保、存提款。
• 排程：每日固定时间执行。
• 资料变动：例如库存低於安全存量、储水量高於满水位、工作流程系统传来一笔资料、物联网接收到感测器资料、系统异常讯息...等。

维基百科有非常棒的定义，最後整理成图四，复杂一点可能变成图五，围绕整个办公室。

图四. 事件风暴的产出，图片来源：Model Event Storming Results in Context Mapper

图五. 事件风暴的产出奇观，图片来源：Make Collaboration Better with Event Storming

最後将事件风暴的产出整理成表格，或像DFD的Context Diagram，就是一份很完整的高阶系统规划书。

3. 聚合(Aggegate)：是将相关的实体(物件)归类在一起，并找到聚合根(Aggegate Root)，亦即主要的实体，它像肉粽串的头，可以藉着它一把抓起所有的实体，类似主资料表，藉由Foreign Key关联其他资料表，例如商品主表，关联产品类别表、各仓库存量表、供应商表...等。
   
   图六. 聚合(Aggegate)

图七. 领域范围(Bounded Context) + 实体(Entity)，图片来源：How the Domain-Driven-Design is the ideal architecture to develop IoT Services?

结语

透过以上的活动，我们就可以得到一个系统的全貌，接下来由上向下(Top Down)展开，逐步细致化，就可以完成整个系统的设计与开发。