【Day 03】初探领域驱动设计

前言

上一篇谈到战略资讯系统的分层设计，要如何进行呢? 中大型企业一般会请管理顾问公司或IBM/HP...等资讯服务公司，协助规划，办理一些共识营的活动，擘划企业愿景、凝聚共识，进而展开至各事业群，订定未来方向，这种由上而下(Top Down)的方式，可以确保企业目标可以藉由各部门的分工与合作，顺利达成。领域驱动设计分为战略与战术设计，其中战略设计也是类似的方式，事件风暴(Event Storming)就是与领域专家、使用者与开发团队凝聚共识的方法。

系统分析方法论的演进

领域驱动设计并不是横空出世，而是经由过去几十年的逐步演化而成的，它是一种系统分析与设计的方法论，现在系统开发人员几乎不太注重系统分析技能了，学校也不注重了，大部分人都是画几张『使用案例图』(Use Case Diagram)、『类别图』(Class Diagram)交差了事，对於复杂的流程，了不起再补张『顺序图』(Sequence Diagram)，这样的作法见树不见林，只注重系统设计，不管系统分析，如此进行中大型系统的开发，几乎注定要失败。

图一. 使用案例图(Use Case Diagram)，图形来源：维基百科

图二. 类别图(Class Diagram)，图形来源：ResearchGate

图三. 顺序图(Sequence Diagram)，图形来源：Zim - A Desktop Wiki

随着中台架构/领域驱动设计的声量变大，笔者很高兴热潮又摆荡回来了，大家又开始讨论系统分析方法论了，领域驱动设计可以搭配各种开发框架及设计模式，使开发者愿意更进一步的将分析与设计做好，形成『分析/设计/开发』一贯的流程，它不像UML，只提供图形工具，参见下图，领域驱动设计则有一套完整的方法论(Methodology)，也就是遵循步骤，就可以顺利的将系统开发出来。当然不保证功能一定会符合使用者的期望，因为那是属於分析技巧与甲乙双方认知的问题。

图四. UML图形工具，图形来源：维基百科

笔者一路看着系统分析方法论的进展，觉得非常有意思，从『结构化分析与设计』(俗称DFD)、UML/RUP到领域驱动设计(DDD)，旧的思维不断的补强，成为更新、更完整的工具，例如：

1. DFD以 System Context Diagram 描述系统与外部系统的介接，藉以框住系统的范围，DDD 转化成 Bounded Context。
2. DFD Level 0的事件列表(Event List)，DDD将之强化为『事件溯源』(Event Sourcing)与『命令和查询职责分离』(CQRS)。
3. 物件导向程序设计(OOP)兴起，UML的类别图(Class Diagram)变成显学，DDD则进一步强化为领域模型，并引入聚合(Aggregate)/聚合根(Aggregate Root)/实体/值对象等概念。
4. 系统设计阶段导入各种设计模式(Design Pattern)，包括Repository/Factory/Facade...等，配合各种现成的框架，如Java Spring、MS MVC、ORM等，期望一气呵成的完成相关系统的开发。

图五. System Context Diagram 与 Bounded Context 比较，图形来源：微软DDD文件指引、维基百科

领域驱动设计

讲了那麽多，领域驱动设计的分析流程是甚麽呢? CQRS Journey画了一张很有趣的图，分为8个步骤，也附了一本书说明详细作法。

不过，笔者比较喜欢另一本书『中台架构与实现：基於DDD和微服务』的思维，针对它建议的流程，稍作修改如下图：

图六. 领域驱动设计流程

在後续的文章，我们会针对每一步骤做详细说明。

结语

看到那麽多的缩写字、专门术语与图形，读者应该很头痛，毕竟研究任一种方法论，都要花很多时间阅读、理解进而实作，但是回报也是呈正比的，笔者就曾经靠『结构化分析与设计』方法论，获得两、三个工作机会，也靠这套方法论，完成数十个应用系统的开发，现在面对『领域驱动设计』的热潮，也是值得再投入时间，将自己的档次再提昇一级。

下一篇，我们会先依照系统分析方法论的演进过程，先介绍早期的『结构化分析与设计』(DFD)，说明其优缺点，再逐步比较领域驱动设计对应的作法。