一、前言
理解业务、理解业务、理解业务，重要事情说三遍！！！
DDD 建模的前提就是要理解业务。
为了让团队中的人交流都在同一平台之上，需要在同一语言之上，理解各种话术。那么就需要理解 DDD 中各种概念。
DDD 中有很多概念：核心域、子域、限界上下文（bounded context）等。
二、概念
（1）限界上下文
一个小型电商系统，也会划分成很多的子系统：订单系统、商品系统、库存系统、WMS 系统、营销系统，等十几个子系统。
限界上下文就是：在大系统（电商系统）下圈定一块小范围，订单系统就是一个限界上下文，商品系统也可以认为是一个限界上下文。
就是给每个小系统都划分一个边界，把每个系统拆分出来，每个都有自己的领域和领地，并不是混合在一起的。
对于一个完整的系统，可以在里面先划分出来多个限界上下文，每个限界上下文可以对应一个子系统，独立的小团队专门负责维护这个子系统以及对应的限界上下文。
例如：订单系统，由一个团队负责维护（二十人）
- 生成系统（五人）
- 价格系统（八人）
- 拆单系统（七人）
一个限界上下文是独立的系统，有独立的代码仓库，独立的工程，独立的数据库，独立的测试环境，独立的维护团队，完全独立开来的，有自己内部的一套通用语言。
记住：限界上下文就代表一个系统。
设定好边界，这个系统内部处理哪些，对外提供哪些服务。
（2）通用语言
通用语言：顾名思义，团队中每个人都会交流工具。
举个栗子：
- 订单系统里，有一个类
Customer，在订单系统这个限界上下文里，指的是下订单的用户。 - 采购系统里，有一个类
Customer，指的不是下订单的用户，是批发商进行批量采购的客户。
同样是 Customer，在不同的系统（限界上下文里），对应的含义是不同的。
在不同的系统对应的限界上下文里，定义出来一批名词（一堆类），代表了这个限界上文里的通用语言。
所以，需要在这个限界上下文里需要对各种核心概念定义一套通用的中文和英文的名词和解释。
只有这个限界上下文里的几个系统的开发工程师，会按照同样的一批通用语言来理解所有的名词，大家对
Customer这个名词的理解是一样。
通用语言：团队每个人对这些中文和英文名词的含义都有共识。
开发流程：
-
从
PM（产品经理）那里理解了系统需求之后。抽象和总结，设计出来一套符合DDD理论的限界上下文、通用语言，按照DDD理论对系统进行了业务建模之后。 -
技术设计：根据
DDD业务建模的结果，设计数据库里的表。说白了，先写类（交互），再设计表。先设计
DDD业务模型、划分系统、设计类、设计表、写代码实现符合DDD的系统交互流程。
问题：这貌似跟先需求分析类似，先画 UML 中类图、时序图、组件图等。
（3）子域
DDD建模的时候，主要关注的就是域这个概念。
子域可分为：
其实就是一个大系统，域之间需要做集成，大系统之间的集成。 对每个域内部进行服务的划分。
-
核心域：决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。
-
支撑域：既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域。
-
通用域：没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。
例如：
HR系统、OA系统、CRM系统、权限系统等，有通用解决方案。可以找到第三方厂商采购并集成，或者内部做。
啥是核心域，非核心域？
- 核心域：公司里极为核心的一个系统，例如商品、订单、库存等系统。
- 非核心域（支撑域）：公司里非核心系统，也可以说是支撑域，例如竞对数据爬虫系统、第三方比价系统、
BI报表系统等。
不支撑公司核心流程运转，主要是锦上添花的系统。
