1 领域
用以确定边界。
DDD按规则细分业务领域，细分到一定程度，DDD会将问题范围限定在特定边界，在该边界内建立领域模型，进而用代码实现该领域模型，解决相应业务问题。
领域就是该边界内要解决的业务问题域。其越大，则业务范围越广。
领域模型的特点
对业务领域建模：
- 细粒度的类，易扩展，易复用
- 可应对复杂业务逻辑
- 需要经验
简单的领域模型：
- 几乎和DB中的表一一对应
- 复杂领域模型
- 使用了继承，组合，设计模式等各种手段
2 子域
领域可再划分为多个子领域，即子域。 每个子域对应一个更小的问题域或业务范围。
DDD是处理复杂领域的设计思想，它试图分离技术实现的复杂度。每个细分的领域都有一个知识体系，即DDD的领域模型。在所有子域研究完后，就建立了领域模型。
比如酒店行业，一开始的酒店核心系统是单体架构，后来业务发展，开始转型中台，引入微服务。微服务架构就需划分业务领域边界，建立领域模型，并实现微服务落地。 可根据业务关联度及流程边界将酒店领域细分为：预订，入住，退房，客房服务，点餐等领域事件。
- 网上预订，入住，退房。是酒店领域一定要有的功能，这就是核心子域。
- 客房服务，点餐等不影响主要功能的就是支撑子领域。
- 在预订这个限界上下文内可以建立预订的领域模型的领域模型最后映射到系统就是预订微服务。
不同行业的业务模型可能不同，但领域建模过程类似，核心思想都是将问题域逐步分解，降低业务理解和系统实现的复杂度。
实际项目划分出的子域更多，但并非每个子域都一样重要。所以，还要继续划分子域，根据自身重要性和功能属性划分为：
2.1 核心域（Core Domain）
决定业务成功和公司核心竞争力的子域，整个系统最重要部分。 Eric Evans 曾提出如下问题助识别核心域：
- 为什么这个系统值得写？
- 为什么不直接买一个？
- 为什么不外包？
若你对这几个问题的回答能够帮你找到这个系统非写不可的理由，那它就是你的专属核心域。
2.2 支撑域（Supporting Subdomain）
不是你的核心竞争力，但又不得不做，市场上也找不到现成方案的子域。既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，但又必需。 支撑域具有企业特性，但不具通用性，如：
- 数据代码类的数据字典等系统
- 要做一个排行榜，可能根据各种信息排名，这种东西没人会按你需要做个，但对你自己，又是扩展自己系统的重要举措
2.3 通用域（Generic Subdomain）
没有太多个性化需求，同时被多个子域使用的通用功能子域。比如认证、权限等，无企业特点限制，无需太多定制化。
行业里都这么做，即便不自己做，也不影响业务运行。如很多 App 要给用户发通知，这种功能完全可买个服务，丝毫不影响业务运行。
2.4 划分子域的意义
划分子域就是在区分不同概念，让他们各司其职。为了区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度和资源投入策略不同：
- 核心域全力投入
- 支撑域次之
- 通用域甚至可以直接花钱买服务
3 总结
领域的核心思想是将问题域逐级细分，降低业务理解和系统实现的复杂度。 通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，映射成系统就是微服务。
