为什么领域驱动那么火？
它解决了架构师的一个通用问题：Do the RIGHT thing RIGHT！
领域驱动架构设计就是以客户和产品为导向，进行业务拆分的一套架构设计思路。
领域设计4层模型
它和我们平时的三层模型有点类似，但也有些不同。
- 第一层：展现和接口层
提供一些API或者图形化界面，或者对外提供了一些封装的接口。 - 第二层：应用层
传统的应用层既负责逻辑也负责一些命令、任务调度、编排策略等等。
而这里的应用层只负责编排 消息 和命令，逻辑下放到第三层。 - 第三层：领域层（领域模型）
领域设计里所有的模型与核心概念都在这一层研发和设计。 - 第四层：基础架构层
这一层包括一些Cache、持久化DAO相关的内容、消息队列、发邮件、日志审计等等
这里领域层是核心，而应用层是需要调领域层，应用层里面可能有应用的服务也可能有领域的服务，这些服务没法抽象成一个个比较容易理解的领域模型，这个时候可以放到应用层处理。
这样一个领域分层模型，会影响到我们每一个模块因素的摆放，也会影响到我们的代码。
领域、子域、界限上下文
- 领域：比如二手商品交易平台
- 子域：支付子域、产品子域、用户认证子域
- 界限上下文：支付上下文、认证上下文
子域提出问题空间，界限上下文提供解决空间。
比如，子域提出支付能力，那么我们就需要搭建一套支付平台，那么这个支付平台就会和产品信息打交道，也会跟个人的用户认证信息打交道，这个和别人打交道的一个独立场景里面所有的功能合在一起，就是支付上下文，这些功能解决的问题就是能够支付，因此子域提供问题，界限上下文解决问题。
核心子域、支撑子域和通用子域
核心子域
核心域里面包含了界限上下文，很多时候电商平台里产品信息属于核心域，交易支付的订单能力是核心域，物流也是核心域，这些都是核心域，就对应到了他们的物流上下文、订单上下文以及产品上下文。
支撑子域
而支撑这些核心的也要有一些子域的，比如你对用户信息有了解，但你怎么知道这个用户更偏向于买贵的需求，还是买便宜的需求呢？
所以这时候你要对用户行为分析进行处理，用户行为分析的结果你不能直接变成钱，你不能把用户分析结果卖给其他公司，公司里所有用户行为只能用于本公司里所有产品对用户进行推荐，这个时候用户行为推荐系统是属于内部支撑子域，他不是用于直接赚钱，而是用于支撑核心域来赚钱的，因此赚钱的能力在于核心域，而支撑它的是支撑子域。
通用子域
除了支撑子域外还有一些很通用的内容，我们叫它通用子域，比如用户认证，用户认证几乎每个电商平台都有，所以一般情况下你不需要自己开发，你完全可以买一些外包，比如一些很知名的用户认证系统，像阿里的用户认证系统、腾讯的用户认证系统。这样你很方便的让用户用微信登录、淘宝登录、支付宝登录等等，这样种种的一些用户登录系统因为每个企业都有，所以你不需要自己开发，你可以抛离给第三方或者开源方法实现，这种子域叫做通用子域，它不会给你赚钱，它的支持粒度也没有其他用户行为分析、用户风控分析等等这么对业务支撑影响那么大，所以你可以用最简单的方法来实现。
界限上下文
说完上面几个子域后，其实每个子域都是通过一个个的界限上下文来真正落地。
上下文关系模式
- 分离模式
互不干扰，各走各道 - 反腐层模式
继承遗留系统，又不能强制老系统更新。新系统要做个适配器层来转换模型。 - 跟随者模式
一定要跟上游系统绑定，但别人是主，本系统是从。 - 客户供应者模式
客户供应商关系，强依赖，上下游系统开发合作顺利，对模型逻辑修改反应迅速。很常见的是消息队列的两端，就是供应商与客户的关系。 - 共享内核模式
共享内核，两团队之间紧密合作，代码模型可以提取成通用组件共享。