DDD—子域和限界上下文

一、域的概念和划分

    DDD对业务领域划分到一定程度后，便将特定问题限定在了特定的边界内，这个特定的边界就是域，在边界内进行领域建模，微服务代码落地。

    边界有大有小，领域可以进一步划分为子域，把问题聚焦到一个特定的业务范围内。

    在领域不断细分的过程中，通常被分解为核心子域，通用子域和支撑子域

    企业内决定核心竞争力的是核心子域里的业务，而没有个性化诉求，不在业务主流程上的为通用子域，另外一种不是企业核心竞争力能力的，但对于核心子域的建设是不可缺少的称为支撑子域，支撑子域和通用子域都可以被多个核心子域重复使用。

    比如电商领域中，营销，推荐，购物，直播是他的核心子域，而这些核心业务逻辑都需要订单，支付，用户信息，所以这部分为通用子域，而支撑子域更多为公共服务的实现，如任何子域都需要使用到的数据字典，国际化，权限认证等。

 

二、核心子域的选择

     比如人作为一个领域的话，身高，体重，背景，外貌，性格，品行是子域，那么对于不同的人来说，核心子域是可以不同的，外貌协会会把外貌作为核心子域，拜金的会把背景作为核心子域。

     在同一个领域，不同核心领域的选择，决定了一个企业的战略方向和商业模式，例如电商领域里，淘宝是C2C，京东是B2C，战略方向和商业模式最终会导致核心领域选择的不同，导致企业的核心投入占比不同。

     所以核心子域的建模，要排在领域建模的首要位置，他会决定企业的投资方向和战略地位。

 

三、限界上下文（Bounded Context）

     限界上下文定义了领域模型的边界和业务适用范围，使得团队所有成员明确什么内容应该在领域模型中实现，什么东西不应该出现

     定义限界上下文通常考虑领域业务职责单一的因素，确定了职责边界后，将所有实现该领域职能相关的对象都放在同一个限界上下文边界内，而将所有与该职能无关的对象排除在上下文边界之外，限界上下文就是一个强制边界，保证领域职责的单一性。

     部门的组织架构划分，实际就是定义部门的限界上下文，企业设置组织架构时，通常从部门职责出发，设立人力资源部，行政部，技术部，销售部，咨询部，部门的只能边界就是企业这个领域的上下文边界。在部门内聚集和部门相关技能的成员，职责。部门边界的区分是为了避免不相干的成员散落在各个部门，给人造成一种组织架构混乱的感觉，觉得这个企业的组织架构不够单一，界限明确，不能够专业的人干专业的事。

     限界上下文本质上就是子域。当一个领域，我们划分的子域足够小的时候，就可以在子域内划分限界上下文，进行领域建模了，如果子域划分得足够小不可再拆分，那么限界上下文刚好和子域的边界一致，如果子域还能再次划分，一个子域内出现多个限界上下文，也是OK的

 

四、共同语言

     三百六十行，行行出状元。在上文的部门职能上下文内，不同部门内的行话也是不一样的，比如技术部用技术相关的语言交流，人力资源部用人力相关的语言交流，这些共同语言组成了部门间的语言上下文边界

     比如电商领域的淘宝，商品在进货阶段叫货物，销售阶段叫宝贝，快递阶段叫快递，一件东西在不同的阶段会有不同的表现形式，由于业务领域边界的不同，需要达成对领域内对象，实体的共同语言描述，避免造成歧义。

    

 

　 参考书籍 ——《基于DDD和微服务的中台架构与实现》欧创新、邓頔
　 参考书籍 ——《领域驱动设计》Eric Evans
　 参考书籍 ——《架构真经》Martin L. Abbott