一、构造块
构造块是指领域设计中最基本的一些元素。
1.1 分层架构
分层是常用的方法，不仅是领域驱动设计，计算机网络也会看到分层思想：网络的七层模型。分层的好处在于：可以集中精力关注每一层的功能职责，更好地分工协作。
分层的基本原则是：层中的任何元素都仅依赖于本层的其他元素或其下层的元素。下层如果不得已要调用上层的话，需要采用合适的模式，如观察者模式或者回调机制等。
常见分层如下：
- 用户界面层（或表示层）：展示信息等。如：web 服务的 Contoller。
- 应用层：协调领域对象。如：支撑 Contoller 的 Service 服务。
- 领域层（或模型层）：表达业务概念、业务状态信息、业务规则。
- 基础设施层：为上面各层提供通用的技术能力。如：数据库操作等。
1.2 关联
模型其实是真实世界模型的一个子集，不需要每个细节都反映出来，关联关系也是如此。
关联描述的是对象之间的联系，作者描述了3种减少关系复杂度的方法：
- 规定一个方向遍历：如，学校和校长是多对多的双向关系，但是如果可以考虑一个校长只在一个学校担任的职务的话，可以简化为学校到校长的1对多的关系。
- 添加一个限定符，以便有效地减少多重关联：如，在学校的某个特定时期，只有一位正校长。
- 消除不必要的关联：按需描述即可，less is more。
1.3 entity
实体 entity 的定义：主要由标识定义的对象被称做entity，特点是在整个生命中具有连续性。
简单理解为领域层中带有意义ID的对象，如：订单信息（含订单ID）。
1.4 value object
值对象 value object 的定义：用于描述领域的某个方面而本身没有概念标识的对象称为 value object。
简单理解为对象属性决定差异的个体，如：颜色RGB对象，只要rgb值一致，那么其实是一种颜色，并不关心对象的本身到底是哪个实例。
这类对象特点：
- 经常作为参数在对象之间传递消息，常常是临时对象。
- 设计选择：复制、共享或保持value object不变。
- 为性能优化提供了更多选择：可缓存、可共享等。
1.5 service
领域层中服务 service 的特征：
- 与领域概念相关的操作不是 entity 或 value object 的一个自然组成部分。
- 接口是根据领域模型的其他元素定义的。
- 操作是无状态的。
简单理解为领域层中一些需要协调多个对象的无状态函数。可以暴露领域中的一些功能。
值得注意的是：
- service不只在领域层使用，根据职责，service也会分到各层中。
- 可以控制领域层中接口的粒度。
1.6 aggregate
聚合 aggregate 是一组相关对象的组合，有一个根（root）和一个边界（boundary）。外部对象只能引用根，而边界之间的内部对象之间则可以相互引用。
1.7 factory
工厂 factory 负责复杂对象和aggreate的创建，是领域设计的一部分。
1.8 repository
存储库 repository 为那些需要直接访问的对象提供数据访问能力，封装底层存储逻辑。
1.9 specifiction
声明 specifiction 是为特殊目的创建了谓词形式的 VALUE OBJECT，是一个谓词，可以用来确定对象是否满足某些标准。
场景：某些业务规则不适合作为Entity 或 VALUE OBJECT 的职责。
二、柔性设计
柔性设计（supple design）：运用深层模型所蕴含的潜力来开发出清晰、灵活且健壮的实现，并得到预期的效果。
2.1 intention-revealing interfaces
释意接口 intention-revealing interfaces：在命名类和操作时要描述它们的效果和目的。
2.2 side-effect-free function
无副作用函数 side-effect-free function：尽可能把程序的逻辑放到函数中，函数不产生明显的副作用，把命令（引起明显状态改变的方法）隔离出来。
2.3 assertion
断言 assertion：对程序某个时刻正确状态的声明，在编程中编写 assertion 或者单元测试。
2.4 conceptual contour
概念轮廓 conceptual contour：领域本身的一致性，把设计元素分解为内聚的单元。
2.5 standalone class
孤立的类 standalone class：无需引用任何其他对象（系统的基本类和基础库除外）就能够理解和测试的类。把无关对象提取到对象之外，保持低耦合。
2.6 closure of operation
闭合操作 closure of operation：闭合操作提供了一个高层接口，同时又不会引入对其他概念的任何依赖。在适当的情况下，可以定义操作的返回类型与参数类型相同。
三、战略设计
战略设计（strategic design）：一种针对系统整体的建设和设计决策。
3.1 bounded context
限界上下文 bounded context：特定模型的界限应用。限界上下文使团队知道什么必须保持一致，什么必须独立开发。
3.2 continuous integration
持续集成 continuous integration：把工作足够频繁地合并到一起，并使它们保持一致。
3.3 context map
上下文图 context map ：项目所涉及的界限上下文以及它们与模型之间的关系的一种表示。描述模型之间的联系点，明确所有通信需要的转换，并突出任何共享的内容。
3.4 shared kernel
共享内核 shared kernel ：通常是共享核心领域或者是一组通用子领域。
3.5 customer/supplier
客户/供应商关系 customer/supplier：上下游关系。不同客户需要协商来平衡，上游团队需要有自动测试套件。
3.6 conformist
跟随者模式 conformist：单方面跟随模式。上游的设计质量较好，容易兼容，可以采用严格遵循上游团队的模型。
3.7 anticorruption layer
防腐层 anticorruption layer：防腐层、隔离层，使用 facade or adapter 等模式。可以减少其它系统变动对本系统的影响。
3.8 separate way
各行其道 separate way：声明一个与其它上下文毫无关联的 bounded context，使开发人员能够在这个小范围内找到简单、专用的解决方案。
3.9 open host service
开放主机服务 open host service：开放子系统供其他系统访问。
3.10 published language
共享语言 published language：把一个良好文档化、能够表达领域信息的共享语言作为公共的通信媒介，必要时在其它信息与该语言之间进行转换。
四、精炼
精炼（distillation）：是把一堆混杂在一起的组件分开的过程，从中提取出最重要的内容，使得它更有价值。
4.1 core domain
核心领域 core domain：模型中最关键的部分，是程序的标志性部分，也是应用程序的核心诉求。
4.2 generic subdomain
通用子领域 generic subdomain：识别出对项目意图无关的内聚子领域，提取通用模型，并分离出来。
4.3 domain vision statement
领域愿景说明 domain vision statement：类似愿景说明文档，关注领域模型的本质，以及如何为企业带来价值。
4.4 highlight core
突出核心 highlight core：编写简洁文档描述 core domain 以及核心元素之间的主要交互过程，并把 core domain 标记出来。
4.5 cohesive mechanism
内聚机制 cohesive mechanism：把内聚的部分分离到一个单独的轻量级框架汇中， 并用释意接口暴露框架功能，从而使得领域元素关注“做什么”，“怎么做”转移给了框架。
4.6 segregated core
分离的核心 segregated core：把核心概念从支持性元素中分离出来，并增强核心的内聚性。把通用元素、支持性元素提取到其它对象中。
4.7 abstract core
抽象核心 abstract core：识别模型中最基本的概念（能表达出主要组件的大部分交互），并分离到抽象模型中（类、抽象类或接口）。抽象模型放在自己的模块中，实现类留在子领域定义的模块中。可以减少模块间依赖的复杂性。
五、大型结构
大型结构（large-scale structure）：一组高层的概念、规则，它为整个系统建立了一种设计模式，能够从更大的角度来讨论和理解系统。
5.1 evolving order
演变有序 evolving order：让概念上的大型结构随着应用程序一起演变，甚至可以变成一种完全不同的结构风格。
5.2 system metaphor
系统隐喻 system metaphor：当系统的一个具体类比正好符合团队成员对系统的想象，并且能够引导他们向着一个有用的方向进行思考时，就应该把这个类比用作一种大型结构。例如：用真实大楼的防火墙来类比网络的防火墙。
5.3 responsibility layer
职责分层 responsibility layer：在具有自然层次的模型中，可以围绕主要职责进行概念上的分层，这样可以结合使用”分层“和”职责驱动的设计“这两个有力的原则。
5.4 knowledge level
知识级别 knowledge level：是一组描述了另一组对象应该有哪些行为的对象。当我们需要让用户对模型的一部分有所控制，而模型又必须满足更大的一组规则情况时，可以利用这个模式来处理。可以通过类型的知识，去选择不同的策略。
5.5 pluggable component framework
可插入式组件框架 pluggable component framework：从接口和交互中提炼出一个抽象核心 abstract core，并创建一个框架，这个框架要允许这些接口的各种不同实现被自由替换。
来源 | 阿里云开发者公众号
作者 | 闵大为
