领域驱动设计_01_基本概念

一、前言

二、领域、子域、限界上下文

1.领域

2.子域

核心域、支撑子域、通用子域

3.限界上下文

（1）边界 限界上下文是一个显示的边界，领域模型边存在于这个边界之内。 在边界内，每一个概念模型，包括其属性和操作，都具有特定的含义。

（2）概念命名 在一个上下文中，团队通常根据通用语言来命名某个概念。

比如两个银行上下文，一个用于支票账户，一个用于储蓄账户。在支票上下文中，我们不必使用 checking account ，也不必在储蓄上下文中使用 saving account ，两个概念都可以使用账户 account 来表示。

4.问题空间和解决方案空间

在领域中还同时存在着问题空间和解决方案空间

• 问题空间 问题空间是领域的一部分，对问题空间的开发将产生一个新的核心域。对问题空间的评估应该同时考虑已有子域和额外所需子域。 因此， 问题空间是由战略核心域及其支撑子域组成
• 解决方案空间 解决方案空间包括一个或多个界限上下文，即一组特定的软件模型。

三、上下文映射图

两种表示方式：

• 简单框图
• 源码实现

1. 9种DDD组织和集成关系

• 开放主机服务
• 发布语言
• 防腐层

2.示例图

四、架构

1. 一个成功案例的架构演进

1.1 SAAS的订阅模型

1.2 六边形架构

1.3 SOA

通过SOA的方式来聚合数据

1.4 CQRS架构

1.5 事件驱动架构

使用管道和过滤器模式实现

1.6 优化1

将管道和过滤器分布化和并行化，这需要加入长时处理过程，有时也加入Sagas.

1.7 优化2

跟踪对系统的每一次改变，采用事件源（Event Sourcing）

2. 分层架构

2.1 分层架构图

分层架构模式被认为是所有架构的始祖。

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

• 用户接口层 : User Interface
• 应用层：Application Layer
• 领域层：
• 基础设施层：Infrastructure Layer

2.2 分层架构原则

分层架构的一个重要的原则是：每层只能与位于其下方的层发生耦合

2.3 分层架构种类

分层架构分类：

• 严格分层架构 某层只能与直接位于其下方的层发生耦合。
• 松散分成架构 允许任意上方层与任意下方层发生耦合。由于用户界面层和应用服务通常需要与基础设施打交道，许多系统都是基于松散分层架构的。

2.4 用户界面

用户界面只用于处理用户显示和用户请求，可对用户输入进行校验，不应该包含领域或业务逻辑。

如果用户界面使用了领域模型中的对象，那么此时的领域对象仅限于数据的渲染展现。在采用这种方式时，可以使用展现模型（Presentation Model），对用户界面和领域模型进行解耦。

由于用户可能是人，也可能是其他的系统，因此有时用户界面层将采用开放主机服务的方式向外提供API

2.5 应用服务

应用服务（Application Service）位于应用层中。

应用服务和领域服务（DomainService）是不同的，因此领域逻辑不应该出现在应用服务中。

应用服务可以用于持久化事务和安全认证，或者向其他系统发送基于事件的消息通知，另外还可以用于创建邮件以发送给用户。

应用服务本身并不处理业务逻辑，但它却是领域模型的直接客户。

应用服务是很轻量的，它主要用于协调对领域对象的操作，比如聚合

聚合的最佳实践：

当需要创建新的聚合时，应用服务应该使用工厂或聚合的构造函数来实例化对象，然后采用资源库对其持久化。应用服务还可以调用领域服务来完成和领域相关的任务操作，但此时的操作应该是无状态的。

存储和转发事件：p106

资源库接口实现放在应用层中： 在分层架构中，领域层或多或少地需要使用基础设施层。这里我并不是说核心的领域对象会直接参与其中，而是说领域层中的有些接口实现依赖于基础设施层。比如资源库接口的实现需要基础设施层提供的持久化机制。

还有更好的方法，参见下文的依赖倒置原则。

2.6 基础设施

2.7 依赖倒置原则

3.六边形架构（端口与适配器）