领域驱动战术设计进度说明

我在GitChat发布的《领域驱动战略设计》课程于2018年10月结束，原计划是在2018年底或2019年初再发布《领域驱动战术设计》课程，没想到一拖再拖，而我自己也终于体会到起点作者的那种催更压力。我本想揣着鸵鸟的心态躲在后面默默地写、慢慢地写，不给自己设定最终期限，没想到读者群里的众多读者已经开始发出了自己的呼声：

我想，我没法再藏起来假装自己不知道，只得站出来给大家汇报。

我计划的《领域驱动战术设计》课程共分为六部分内容，分别为：

• 领域模型

• 分析模型

• 设计模型

• 实现模型

• 融合

• 案例分析：EAS系统

领域驱动设计的核心是模型驱动设计，但Eric Evans并没有费太多笔墨来探讨“模型”。我认为讨论任何技术问题，都应该先明确技术概念的含义，在达成一致认识的前提下，才谈得上该如何设计与实现。

我发现许多人在争执领域驱动设计的问题时，甚至都没有分清楚什么是领域建模，什么是数据建模，二者的差异又是什么？因此，我希望在本部分对“模型”来一个彻底的讨论，阐释模型在软件设计中的角色和价值，并比较数据模型、服务模型和领域模型之间的区别。

对于领域驱动的分层架构，我在《领域驱动战略设计》课程中已有深入分析，但我发现很多读者依然会混淆各个层次中的模型，例如什么是DTO？什么是持久化对象？它们和领域对象之间的关系？这些问题真的是剪不断理还乱。所谓“正本清源”，要掌握领域驱动设计，这些概念是需要甄别清楚的。

本部分，我还比较了事务脚本、表模块和领域模型，并由此探讨了模型与编程范式之间的关系。

在第一部分，我将领域模型分为分析领域模型、设计领域模型和实现领域模型三种模型，故而接下来的三个部分我将开展对这三个模型的介绍。

分析模型是在分析阶段进行建模后的结果，由于领域驱动设计强调以领域为核心，因而由领域专家与开发团队达成一致的统一语言将在分析模型中扮演非常重要的角色。

软件分析是一种技能，但我们也可以借鉴一些方法，来帮助我们提高分析的能力。因此，在本部分我会利用分析模式、四色建模和事件风暴来帮助我们获得分析模型。若有可能，我还希望再加上一个ICONIX方法，虽然它已经垂垂老矣，但该方法蕴含的一些设计思想仍有值得借鉴之处。

这部分才真正进入领域驱动战术设计的内容，你会看到实体、值对象、领域服务、领域事件等耳熟能详的设计要素。即便如此，针对这些基本的设计要素，许多读者仍然存在对它们的理解差异，我希望能够说清楚这些设计要素，并结合案例来展现一个正确的领域模型会给我们带来什么样的价值。

聚合在领域驱动设计中极为关键，是Eric Evans提出的一个非比寻常的创见。然而，一直以来，我们却不知道该如何设计高质量的聚合，我希望我能尽量帮助读者理解聚合的意义，以及识别聚合的原则和方法。

在领域驱动设计中，许多人常常分不清楚领域服务和应用服务之间的差异，也没有能够理解资源库和DAO之间的区别，针对这些棘手问题，我会努力给出清楚的答案。

从本质上讲，Eric Evans的领域驱动设计其实就是对面向对象设计的运用。如何进行良好的面向对象设计呢？“职责”才是面向对象的核心，因此我将结合案例阐释我对职责驱动设计的理解，并给出可行的设计方法与过程。

DCI模式与职责协作有相似之处，它强调在不同场景（Context）中各个角色之间的协作。理解DCI，有助于我们理解什么是多态，什么是SPI。许多设计本质其实是愈辩愈清的。

实现模型基本可以认为是代码模型，我希望通过这部分内容回答常见的实现难题，包括：

• 贫血模型与充血模型的问题
  

• 领域模型与持久化

• 通过事务保证不变量与一致性

在这部分内容中，我还将引入重构、测试驱动开发和整洁代码的知识，以求实现模型在代码层面能够清晰直观地体现统一语言。