(DDD)实现领域驱动设计

DDD将领域专家和开发人员聚集到一起，这样所开发的软件能够反映出领域专家的思维模型

DDD关注业务战略，战略设计用于清楚地界分不同的系统和业务关注点，这样可以保护每个业务层面的服务。更进一步，这将指引我们如何实现面向服务架构（serviceoriented architecture）或者业务驱动（business-driven architecture）架构

通过使用战术设计建模工具，DDD满足了软件真正的技术需求。这些战术设计工具使开发人员能够按照领域专家的思维模型开发软件。

业务意图不明确

方法的实现本身增加了潜在的复杂性

领域对象根本就不是对象，而只一个数据持有器

上下文术语：就现在来说，可以将限界上下文看成是整个应用程序之内的一个概念性边界。这个边界之内的每种领域术语、词组或句子——也即通用语言，都有确定的上下文含义。在边界之外，这些术语可能表示不同的意思

通用语言：通用语言是团队共享的语言。领域专家和开发者使用相同的通用语言进行交流，团队中的所有参与者都应该使用通用语言，通用语言是团队自己创建的公用语言，团队中同时包含领域专家和软件开发人员

如何掌握通用语言

每个限界上下文都有自己的通用语言，而有时语言间的术语可能有重叠的地方

获得了一个非常有用的领域模型

业务得到了更准确的定义和理解

领域专家可以为软件设计做出贡献

更好的用户体验

清晰的模型边界

更好的企业架构

敏捷、迭代式和持续建模

使用战略和战术新工具

为创建通用语言腾出时间和精力

持续地将领域专家引入项目

改变开发者对领域的思考方式

限界上下文是显式的，充满语义的

限界上下文主要是一个语义上的边界，我们应该通过这一点来衡量对一个限界上下文的使用正确与否

不需要大而全的模型，模型要限制在限界上下文内

一个限界上下文并不是只包含领域模型

限界上下文主要用来封装通用语言和领域对象，但同时它也包含了那些为领域模型提供交互手段和辅助功能的内容。需要注意的是，对于架构中的每个组件，我们都应该将其放在适当的地方。

核心领域之外的概念不应该包含在限界上下文中。如果一个概念不属于你的通用语言，那么一开始你就不应该将其引入到模型中

上下文映射图主要帮助我们从解决方案空间的角度看待问题

识别出项目中的每一个模型并确定它的限界上下文……为每个限界上下文命名，该名字应该是通用语言的一部分。描述模型之间的连接点，将模型间的翻译转换显式地勾勒出来

合作关系（Partnership）：如果两个限界上下文的团队要么一起成功，要么一起失败，此时他们需要建立起一种合作关系。他们需要一起协调开发计划和集成管理。两个团队应该在接口的演化上进行合作以同时满足两个系统的需求。应该为相互关联的软件功能制定好计划表，这样可以确保这些功能在同一个发布中完成。

共享内核（Shared Kernel）：对模型和代码的共享将产生一种紧密的依赖性，对于设计来说，这种依赖性可好可坏。我们需要为共享的部分模型指定一个显式的边界，并保持共享内核的小型化。共享内核具有特殊的状态，在没有与另一个团队协商的情况下，这种状态是不能改变的。我们应该引入一种持续集成过程来保证共享内核与通用语言（1）的一致性。

客户方-供应方开发（Customer-Supplier Development）：当两个团队处于一种上游-下游关系时，上游团队可能独立于下游团队完成开发，此时下游团队的开发可能会受到很大的影响。因此，在上游团队的计划中，我们应该顾及到下游团队的需求。

遵奉者（Conformist）：在存在上游-下游关系的两个团队中，如果上游团队已经没有动力提供下游团队之所需，下游团队便孤军无助了。出于利他主义，上游团队可能向下游团队做出种种承诺，但是有很大的可能是：这些承诺是无法实现的。下游团队只能盲目地使用上游团队的模型。

防腐层（Anticorruption Layer）：在集成两个设计良好的限界上下文时，翻译层可能很简单，甚至可以很优雅地实现。但是，当共享内核、合作关系或客户方-供应方关系无法顺利实现时，此时的翻译将变得复杂。对于下游客户来说，你需要根据自己的领域模型创建一个单独的层，该层作为上游系统的委派向你的系统提供功能。防腐层通过已有的接口与其他系统交互，而其他系统只需要做很小的修改，甚至无须修改。在防腐层内部，它在你自己的模型和他方模型之间进行翻译转换。

开放主机服务（Open Host Service）：定义一种协议，让你的子系统通过该协议来访问你的服务。你需要将该协议公开，这样任何想与你集成的人都可以使用该协议。在有新的集成需求时，你应该对协议进行改进或者扩展。对于一些特殊的需求，你可以采用一次性的翻译予以处理，这样可以保持协议的简单性和连贯性。

发布语言（Published Language）：在两个限界上下文之间翻译模型需要一种公用的语言。此时你应该使用一种发布出来的共享语言来完成集成交流。发布语言通常与开放主机服务一起使用。

另谋他路（SeparateWay）：在确定需求时，我们应该做到坚决彻底。如果两套功能没有显著的关系，那么它们是可以被完全解耦的。集成总是昂贵的，有时带给你的好处也不大。声明两个限界上下文之间不存在任何关系，这样使得开发者去另外寻找简单的、专门的方法来解决问题。

大泥球（Big Ball of Mud）：当我们检查已有系统时，经常会发现系统中存在混杂在一起的模型，它们之间的边界是非常模糊的。此时你应该为整个系统绘制一个边界，然后将其归纳在大泥球范围之列。在这个边界之内，不要试图使用复杂的建模手段来化解问题。同时，这样的系统有可能会向其他系统蔓延，你应该对此保持警觉。

ACL表示防腐层

OHS表示开放主机服务

PL表示发布语言

在分层架构中，我们将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层逻辑的依赖，因为它们不属于业务逻辑。将一个复杂的系统分为不同的层，每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。

原则

DDD经典分层

通过依赖导致实现底层调用上层

有趣的是，当我们在分层架构中采用依赖倒置原则时，我们可能会发现，事实上已经不存在分层的概念了。无论是高层还是低层，它们都只依赖于抽象，好像把整个分层架构给推平了一样。

六边形架构也称为端口与适配器。对于每种外界类型，都有一个适配器与之相对应。外界通过应用层API与内部进行交互。

六边形架构的一大好处在于，我们可以轻易地开发用于测试的适配器。整个应用程序和领域模型可以在没有客户和存储机制的条件下进行设计开发。

面向服务架构（Service-Oriented Architecture，SOA）对于不同的人来说具有不同的意思。

SOA宣言给我的感觉是，我既可以将服务看作一系列的SOAP/WSDL接口，也可以将其看成为一组REST资源

REST作为一种架构风格

架构风格之于架构就像设计模式之于设计一样。它将不同架构实现所共有的东西抽象出来，使得我们在谈及到架构时不至于陷入技术细节中

RESTful HTTP服务器的关键方面

RESTful HTTP客户端的关键方面

REST和DDD

为什么是REST

一个方法要么是执行某种动作的命令，要么是返回数据的查询，而不能两者皆是。

CQRS旨在解决数据显示复杂性问题，而不是什么绚丽的新风格以使你的简历增光添彩。

查询模型也被称为读模型，同样，命令模型也被称为写模型。

事件驱动架构（Event-Driven Architecture，EDA）是一种用于处理事件的生成、发现和处理等任务的软件架构。

基于消息的系统通常呈现出一种管道和过滤器风格。

管道和过滤器

长时处理过程（也叫Saga）

执行器和跟踪器

事件源

数据缓存

数据复制

持续查询

分布式处理

当我们需要考虑一个对象的个性特征，或者需要区分不同的对象时，我们引入实体这个领域概念。一个实体是一个唯一的东西，并且可以在相当长的一段时间内持续地变化。

工作重点不应该是数据库

在设计实体时，我们首先需要考虑实体的本质特征，特别是实体的唯一标识和对实体的查找，而不是一开始便关注实体的属性和行为。只有在对实体的本质特征有用的情况下，才加入相应的属性和行为

值对象可以用于存放实体的唯一标识。值对象是不变（immutable）的，这可以保证实体身份的稳定性，并且与身份标识相关的行为也可以得到集中处理。

常用的创建实体身份标识的策略

挖掘实体的重要属性

挖掘实体的关键行为

角色和职责

创建

验证

在将领域概念建模成值对象时，我们应该将通用语言考虑在内，这是建模值对象的首要原则

它度量或者描述了领域中的一件东西

它可以作为不变量

它将不同的相关的属性组合成一个概念整体

当度量和描述改变时，可以用另一个值对象予以替换

它可以和其他值对象进行相等性比较

它不会对协作对象造成副作用

在有可能的情况下使用值对象来完成限界上下文之间的集成，这对于许多需要消费标准类型的上下文来说都是适用的。

值对象便是建模度量和描述概念的最佳方式

在限界上下文中，如果没有必要维护一个描述类型对象的生命周期，那么请将其建模成值对象

使用Java的枚举则是非常简单的，与通过状态模式来创建标准类型相比，枚举可能是更好的方法。我认为这里我们同时得到了两种方法的好处。一方面我们获得了一个非常简单的标准类型，另一方面又能有效地表示当前的状态

建议尽量使用枚举来表示标准类型，即便你认为某个标准类型更像一种状态模式。如果存在大量的标准类型实例，我们可以考虑通过代码生成来创建枚举

在创建测试时，我们应该保证领域专家能够读懂这些测试，即测试应该具有领域含义

只有主构造函数才能使用自委派性来设置属性值，除此之外，其他方法都不能使用setter方法

在设计值对象时，我们也不应该完全地遵循JavaBean规范。比如，JavaBean规范要求我们提供公有的setter方法，而这将违背值对象的不变性特征

一个对象的setter和getter方法并不见得只局限于设置对象的属性值，还可以进行断言[Evans]操作，这对于通常的软件开发和DDD模型来说都是很重要的

守卫断言能够，并且应该用于任何有可能接受错误参数的地方。

拒绝由数据建模泄漏带来的不利影响

面临这种阻抗失配时，你应该从领域模型的角度，而不是持久化的角度去思考问题

问问自己以下几个问题

在可能的情况下，尽量根据领域模型来设计数据模型，而不是根据数据模型来设计领域模型

DDD不是关于如何根据范式来组织数据的，而是在一个一致的限界上下文中建模一套通用语言。在这个过程中，你应该尽量地避免数据模型从你的领域模型中泄漏到客户端中

采用隐藏委派主键的方式将值对象集合映射成一对多的关系要简单得多

尽量使用值对象的重要性

不要将领域服务与应用服务混杂在一起了。在应用服务中，我们并不会处理业务逻辑，但是领域服务却恰恰是处理业务逻辑的

当领域中的某个操作过程或转换过程不是实体或值对象的职责时，此时我们便应该将该操作放在一个单独的接口中，即领域服务。请确保该领域服务和通用语言是一致的；并且保证它是无状态的。

领域模型主要关注于特定于某个领域的业务，同样，领域服务也具有相似的特点。由于领域服务有可能在单个原子操作中处理多个领域对象，这将增加领域服务的复杂性。

执行一个显著的业务操作过程

对领域对象进行转换

以多个领域对象作为输入进行计算，结果产生一个值对象

领域模型和消息设施共享持久化存储（比如，数据源）

领域模型的持久化存储和消息持久化存储由全局的XA事务（两阶段提交）所控制

在领域模型的持久化存储中，创建一个特殊的存储区域（比如一张数据库表），该区域用于存储领域事件

如果多个客户方都可以通过单个URI来请求相同的事件通知，那么此时REST便是合适的

如果一个或多个消费方需要从多个发布方中获取资源以顺序地完成一系列任务，那么此时你便会感到REST所带来的痛苦了

在一致性边界之内建模真正的不变条件

设计小聚合

通过唯一标识引用其他聚合

在边界之外使用最终一致性

创建具有唯一标识的根实体

优先使用值对象

使用迪米特法则

告诉而非询问原则

乐观并发

避免依赖注入

一个资源库应该模拟一个Set集合。无论采用什么类型的持久化机制，我们都不应该允许多次添加同一个聚合实例。另外，当从资源库中获取到一个对象并对其进行修改时，我们并不需要“重新保存”该对象到资源库中

将资源库接口定义放在了与聚合相同的包中，而将资源库的实现类放在了impl子包中，这种方式被大量的Java项目所采用。然而，在协作上下文中，团队成员们将实现类放在了基础设施层中：

我们应该避免使用一对一关联，而应该使用多对一的单向关联

强烈反对由聚合来管理持久化，同时我强烈地提倡只使用资源库来处理持久化

这正是使用资源库的正确方法——要么只读，要么读取就是为了修改

其中一种便是在一个限界上下文中暴露应用程序编程接口（API），然后在另一个限界上下文中通过远程过程调用（RPC）的方式访问该API。

另一种直接的集成方式便是使用消息机制。

第三种集成限界上下文的方式是使用RESTful HTTP。有人认为REST也是某种形式的RPC，其实并非如此。

还可以通过共享文件和数据库的方式进行集成，但是此时我只能说，你也太不与时俱进了。

• 网络是不可靠的。

• 总会存在时间延迟，有时甚至非常严重。

• 带宽是有限的。

• 不要假设网络是安全的。

• 网络拓扑结构将发生变化。

• 知识和政策在多个管理员之间传播。

• 网络传输是有成本的。

• 网络是异构的。

当一个限界上下文以URI的方式提供了大量的REST资源时，我们便可称其为开放主机服务

RESTful HTTP，他们认为这种方式的好处在于不用向客服方暴露自身领域模型的结构和行为细节

开放主机服务的部分定义的：“在有新的集成需求时，对协议进行改进和扩展。”

使用防腐层实现REST客户端

资源库通常是用来持久化和重建聚合的，将其用于创建值对象似乎就不合适了。当然，如果我们的目的就是要通过防腐层创建聚合，那么资源库便是一种自然的选择。

在使用消息进行集成时，任何一个系统都可以获得更高层次的自治性。只要消息基础设施工作正常，即使其中一个交互系统不可用，消息依然可以得到发送和投递。

在DDD中，增强系统自治性的一种方式便是使用领域事件。

我们需要考虑到事件的唯一性以便对每个事件进行记录。当事件发生时，系统将通过消息机制将这些事件发送到对事件感兴趣的相关方。

职责分离却并非琐碎之事，至少在使用消息机制时是这样的

需要考虑到消息无序抵达的情况和多次投递的情况[1]

在有可能的情况下，我们应该最小化不同限界上下文之间的信息复制，甚至彻底消除。当然，要完全避免信息复制是不可能的

长时处理过程

渲染领域对象

渲染数据传输对象

使用调停者发布聚合的内部状态

在没有必要使用DTO时，我们可以使用另一种改进方法。该方法将多个聚合实例中需要显示的数据汇集到一个领域负载对象（Domain Payload Object，DPO）

DPO中包含了对整个聚合实例的引用，而不是单独的属性。

通过资源库获取到所需聚合实例，然后创建DPO实例，该DPO持有对所有聚合实例的引用

由于DPO持有的是对整个聚合实例的引用，延迟加载的对象/集合并未被加载到内存中

要解决延迟加载的问题，我们可以选择即时加载，或者使用领域依赖求解器（Domain Dependency Resolver，DDR）

应用服务负责用例流的任务协调，每个用例流对应了一个服务方法。在使用ACID数据库时，应用服务还负责控制事务以确保对模型修改的原子提交。另外，应用服务还会处理和安全相关的操作。

将应用服务与领域服务（7）等同起来是错误的。

我们应该将所有的业务领域逻辑放在领域模型中，不管是聚合、值对象或者领域服务；而将应用服务做成很薄的一层，并且只使用它们来协调对模型的任务操作。

可以使用单个标准输出端口，然后为不同种类的客户端创建不同的适配器

资源库的实现被放在了基础设施层中，因为它们负责处理数据存储，而这些不属于模型的职责。你可以使基础设施层实现那些与消息相关的接口，比如消息队列和E-mail等。如果还有一些特殊的用户界面组件来处理诸如图表之类的展现，那么它们也应该放在基础设施层中。