实现领域驱动设计- 概述

DDD 总览

模型： 对现实的解释 —— 把与问题密切相关的部分抽象出来，而忽略无关的细节。
领域： 软件是为了解决用户的具体需求，这些用户应用软件的问题区域就是软件的领域。
领域模型（Domain Model）：对问题有组织、有选择的抽象。
通用语言 （Ubiquitous Language）
限界上下文（Bounded Context）

限界上下文是一种概念上的边界，领域模型作用于其中。
在一个特定的限界上下文中，只使用一套通用语言，并且保证它的清晰性和简洁性。

战略建模

上下文映射图（Context Map）
问题域
解决方案域

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

使用上下文映射图展示限界上下文之间的关系，来理解项目的范围。

上下文映射图展示限界上下文之间的关系

架构 （Architecture）

架构 （Architecture）
六边形（Hexagonal）架构

一个新的限界上下文或者上下文映射图可能需要一个新的架构。但是领域模型应当是架构中立的。模型周围与模型之间是存在架构的。
一种能够支撑限界上下文的架构是六边形（Hexagonal）架构，他可以辅助其他架构风格，比如SOA，REST，Event-Driven Architecture.
架构并非一成不变，业务的领域建模更加重要，因此不要本末倒置。

战术建模

实体（Entity）
聚合（Aggregate）
值对象（Value Object）
资源库（Repository）
领域服务（Domain Service）
领域事件（Domain Event）
模块（Module）

限界上下文中进行战术建模。
战术设计的一个重要模式是聚合（Aggregate）， 聚合可以是实体，也可以是实体和值对象，在聚合的生命周期中，必须保持事务的一致性。
聚合通过资源库进行持久化。

领域建模中，有些业务操作不能很自然的放在实体或者值对象上，此时可以使用无状态的领域服务（Domain Service）。

领域事件（Domain Event）表示领域模型中发生的重要事件。比如在对聚合进行命令操作时，聚合本身将发布领域事件。

模块（Module）类似于Java中的包，如果机械的设计模块而不是根据通用语言，那么将得不偿失。模块中的领域对象应该是类聚在一起的。