DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。
领域驱动设计的主要名词介绍
领域：业务所在的问题域、要解决的问题
子域：领域进一步细分后的子领域，可以根据属性分为：核心子域、通用子域、支撑子域
核心子域：企业核心竞争力，同业企业可能会因为战略方向不同，核心域会有所不同
通用子域：被多个子域复用的子域，领域建模时需要关注标准和通用性
支撑子域：企业业务运行时必须的子域，非核心非通用子域
事件风暴：领域建模方法，通过业务场景分析，找出领域对象，构建聚合，划分限界上下文
聚合：高度依赖的聚合根、实体和值对象的集合
聚合根：根实体，有全局唯一标识
实体：聚合内唯一标识，有生命周期
值对象：关注数值、无标识、不可变更
限界上下文：微服务拆分的依据，用来封装通用语言和领域对象，保证领域内的
通用语言：通过团队交流达成共识的、能够简单、清晰、准确描述业务含义和规则的语言
领域驱动设计的四个步骤
事件风暴：
- 产品愿景和价值定位
- 找出核心域
- 事件风暴
命令风暴：
- 识别命令
- 识别外部系统触发的命令
- 识别用户
寻找聚合：
- 找名词识别领域模型
- 细分领域模型
- 验证领域模型与领域对象的内聚性
划分限界上下文：
- 划分上下文
- 验证上下文内概念完整性
