DDD领域驱动设计（领域，子域，界限上下文）

       

       

领域与具体开发技术无关。就是软件系统要解决的实际问题相关的所有东西的集合。比如电子商城卖书，那么如何进货，如何决定优惠规则，如何安排物流，如何管理客户级别，如何分析销售数据等等，这直接与业务相关的所有东西都归属于“领域”。DDD就是说你得先把领域中涉及到的数据、流程、商业规则等都弄明白了，然后以面向对象的观点为其建立一个模型（领域模型），再选用合适的软件技术去实现这个模型。

       问题空间是核心域和其他子域的组合。解决方案空间包括一个或者多个限界上下文，即一组特定的软件模型。这是因为限界上下文本身就是一个特定的解决方案。
       领域可再划分为多个子领域，即子域。每个子域对应一个更小的问题域或业务范围。比如酒店行业，一开始的酒店核心系统是单体架构，后来业务发展，开始转型中台，引入微服务。微服务架构就需划分业务领域边界，建立领域模型，并实现微服务落地。可根据业务关联度及流程边界将酒店领域细分为：预订，入住，退房，客房服务，点餐等领域事件。

        网上预订，入住，退房。是酒店领域一定要有的功能，这就是核心子域。
        客房服务，点餐等不影响主要功能的就是支撑子领域。
在预订这个限界上下文内可以建立预订的领域模型，领域模型最后映射到系统就是预订微服务。
不同行业的业务模型可能不同，但领域建模过程类似，核心思想都是将问题域逐步分解，降低业务理解和系统实现的复杂度。

领域可细分为不同子域，子域可根据自身重要性和功能属性划分为三类子域：

1 核心域
决定产品和公司核心竞争力的子域，是业务成功的主要因素和公司的核心竞争力。

2 通用域
没有太多个性化需求，同时被多个子域使用的通用功能子域。比如认证、权限等，无企业特点限制，无需太多定制化。

3 支撑域
既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，但又是必需的支撑域。支撑域具有企业特性，但不具通用性，例如数据代码类的数据字典等系统。

领域的核心思想是将问题域逐级细分，降低业务理解和系统实现的复杂度。
通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，映射成系统就是微服务。

4 界限上下文

        界限上下文就是边界的意思。通过从业务边界到工作边界再到应用边界这三个层次抽丝剥茧，分别以不同的视角、不同的角色协作来运用对应的设计原则，会是一个可行的识别限界上下文的过程方法。

        两个限界上下文之间的关系是有方向的，领域驱动设计使用两个专门的术语来表述它们：“上游（Upstream）”和“下游（Downstream）”，在上下文映射图中，以 U 代表上游，D 代表下游，理解它们之间的关系，正如理解该术语隐喻的河流，自然是上游产生的变化会影响到下游，反之则不然。故而从上游到下游的关系方向，代表了影响产生的作用力，影响作用力的方向与程序员惯常理解的依赖方向恰恰相反，上游影响了下游，意味着下游依赖于上游。