What's DDD?

DDD的目标：创建可测试、可伸缩、组织良好的软件模型。

DDD不是关于技术的，而是关于讨论、聆听、理解和发现业务价值的，都是为了将知识集中起来。
但是并不是说技术不重要，尤其是涉及到架构与模块设计，之间的设计模式以及一些面向对象的思想。

什么是领域模型？
领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。

Why DDD?

软件开发过程中的问题：

• “随着业务的扩展，软件开发投资越来越大” 团队的规模也开始变得越来越大，软件系统的投资和维护的成本变得越来越高。
• “业务人员不懂架构，架构师不懂代码，开发人员不不懂业务模型” 当团队中的关键角色谁也不懂谁的时候，问题来了。。。
• “重构是好的，但什么时候要重构？重构到什么样的架构就是够⽤的了？” 每个有追求的团队都在做重构，但管理者更关心，什么时间必须要重构？重构的目标在哪？

采用DDD的原因：

• 业务沉淀，知识共享
• 业务人员及技术人员之间信息的准确传递
• 帮助业务人员与技术人员自我提高
• DDD同时提供了战略设计与战术设计。战略设计帮助我们理解哪些投入是重要的；哪些软件资产是可以复用的；哪些人应当被加入到团队中。战术设计则帮助我们创建DDD模型中的各个部件。

DDD如何帮助我们？
DDD主要关注三个方面：

• 将领域专家与开发人员聚集到一起，创建一套适用于领域建模的通用语言。通用语言必须在全队内部达成一致。
• DDD关注业务战略。战略设计用于清楚的区分不同的系统与业务关注点；更进一步指引我们实现面向服务架构（SOA）或者业务驱动架构（BDA）
• 通过使用战术设计建模工具，满足软件真正的技术需求。

DDD的业务价值：

• 业务得到更准确的定义与理解
• 领域专家也能参与到软件设计中来
• 更好的用于体验
• 企业架构
• 敏捷、迭代、持续建模

When DDD?

• 业务复杂度高
• 需求的未知性
• 领域的未知性

Adapted from Martin Fowler's PoEAA

处理领域复杂性
将重要的、复杂的模型称为核心域（Core Domain）。
将相对次要的称为支撑子域（Supporting Subdomain）。

贫血领域对象（Anemic Domian Model）
缺少内在行为的领域对象。

• 业务没有沉淀在对应的模型中；
• 随时间推移，业务逻辑被遗忘；代码风险变高

How DDD?

对于初步接触DDD的团队而言，事件风暴工作坊是一个很好的开始。可以参考写过的一篇事件风暴工作坊的实践和总结和网上的一些其他资源。

以下是从DDD的经典书籍中摘录的一些实践方式。
DDD两大支柱：通用语言（Ubiquitous Language）和限界上下文（Bounded Context）。
通用语言是团队的共享语言。领域专家与开发者使用相同的通用语言进行交流。通用语言的更改，就是对领域模型的更改。
通用语言的缺失将造成高昂的解释与误解沟通成本。
限界上下文（Bounded Context）是应用程序的一个概念性边界，这个边界内的各种领域属于——也就是通用语言，有确定的上下文含义。在边界之外，这些术语可能表示不同的意思。

如何制定通用语言？

• 绘制物理模型图，概念模型图等，标以名字和行为
• 创建一个包含简单定义的术语表
• 如果不喜欢术语表，也可以采用其他类型的文档。同时将那些“不正式的”模型图也给包括进去
• 与团队其他成员来检验成本，并且沟通迭代

TIPS:

• 通用语言通常只在团队范围内使用，表示一个单一的领域模型
• 如果试图创建企业级乃至更大范围的通用语言时，几乎一定会失败
• 通用语言与限界上下文有一对一的关系
• 限界上下文也很小，刚好可以容纳一个独立业务领域使用的通用语言
• 每个限界上下文有自己的通用语言，和其他限界上下文打交道时，可以通过上下文映射图来集成。

实现DDD的挑战

• 创建通用语言时候，时间精力的投入
• 持续的引入领域专家
• 改变开发者对领域的思考方式

DDD与敏捷结合的实践

结合Scrum的思想，DDD也倾向于“测试先行，逐步改进的策略”。
即便再专业的领域专家，也无法在业务初期进行完美的设计。
开发一个新的领域对象时，可以采用以下步骤：

• 编写测试代码，模拟客户端使用该领域对象
• 创建该领域对象以使测试代码可以编译通过
• 对测试与领域对象重构。测试能正确的模拟客户代码，领域对象可以表明业务行为
• 实现领域对象
• 向团队成员，包括领域专家，展示代码，以保证领域对象能正确的反映通用语言