DDD-领域驱动设计

0.定义 Definitions

领域 domain

一个关于知识、影响或活动的范围。对于软件来说，其领域就是用户使用程序时所作用到的主题范围（subject area）。

模型 model

一个描述某领域特定方面的抽象系统，可用于解决与该领域相关的问题。

统一语言 ubiquitous language

一种围绕领域模型构建的语言，在一个限界上下文中由所有团队成员使用，用于将团队的所有活动与所开发的软件联系起来。

上下文 context

一个使用词汇和语句的环境，这个环境决定了该词汇或语句的含义。只有在一个上下文中，关于模型的语句才能被理解。

限界上下文 bounded context

对一个边界(通常是一个子系统，或者一个特定团队的工作)的描述。一个特定的模型在该边界内被定义和应用。

I. 让模型发挥作用 Putting the Model to Work

领域驱动设计（Domain‐Driven Design，DDD）是一种开发复杂软件的方法。使用这种方法时，我们:

• 专注核心域（core domain）。
• 通过领域人员和软件人员的创造性协作来探索模型。
• 在明确的限界上下文（bounded context）中使用统一语言（ ubiquitous language）。
• 本手册定义了DDD的上述三点概述中的术语。

许多项目虽然进行了建模，但最终没有取得太多成效。而DDD中的模式则是从那些在建模中获得了显著收益的项目中提取的成功实践。总的来说，这些模式提出了一种完全不同的建模和软件开发方法，兼顾了软件的细节和高阶愿景。一方面要考虑严格的建模约定，另一方面又要通过与非技术人员的协作对模型进行自由地探索。必须在这两者之间取得平衡。战术和战略必须结合起来才能成功，DDD解决了战术设计和战略设计两方面的问题。

1.1 限界上下文 Bounded Context

在任何大型项目中都存在多个模型。这有很多原因。例如，两个子系统通常服务于非常不同的用户社区，完成不同的工作，这时就可以使用不同的模型。又如，由于缺乏沟通，独立工作的团队可能会以不同的方式解决相同的问题。开发团队使用的工具集也可能不同，因此不能共享程序代码。

多个模型是不可避免的。但将不同模型的代码组合在一起时，软件就会变得容易出错、不可靠并且难以理解。团队成员之间的交流也变得混乱。一个模型不能用于哪个上下文，常常是不清楚的。

就像表述其他事物一样，对模型的表述只有在上下文中才有意义。

因此：

显式地定义模型所应用的上下文。根据不同的因素显式地设置边界，例如团队组织；对应用程序特定部分的使用；以及物理表现形式，诸如代码库和数据库模式等。应用持续集成来保持模型的概念和术语在边界内的严格一致。但在保持一致性时不要因边界外部的问题分心或混淆。在上下文中建立一个标准化的开发过程，该过程不需要在其他地方使用。