一、前言
二、领域、子域、限界上下文
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 依赖倒置原则
