DDD中的领域、子域和限界上下文的说明

￡神魔★判官ぃ 2022-12-16 06:19 137阅读 0赞

原文地址：[https://www.deathearth.com/1242.html][https_www.deathearth.com_1242.html]

> 领域

领域即是一个组织所做的事情以及其中所包含的一切。每个组织都有它自己的业务范围和做事方式。这个业务范围以及在其中所进行的活动便是领域。当你为某个组织开发软件时，你面对的便是这个组织的领域。这个领域对你来说应该是清晰的，因为你在此工作。

领域既可以表示整个业务系统，也可以表示其中的某个核心域或者支撑子域。

> 工作中的子域和限界上下文

一个零售商在线销售产品的例子。要在这个领域中开展业务，该零售商必须向买家展示不同类别的产品，允许买家下单和付款，还需要安排物流。在这个领域中，零售商的领域可以分为4个主要的子域：产品目录（product catalog）、订单（order）、发票（Invoicing）和物流（shipping），下图的上半部分表示了这样一个电子商务系统。下半部分增加了一个库存系统。

![一个含有子域和限界上下文的领域][d3067a7b88854fb0ef3edbbef69fdcf1.png]

（上图中我们可以找出多个隐式的领域模型，它们没有很好的被分离出来）

通过DDD战略设计工具，可以按照实际功能将这些交织的模型划分成逻辑上相互分离的子域，在一定程度上减少系统的复杂性。

原文中的一个joke

LB:"有护栏隔离时，我和令居相处的很好，护栏坏了以后，情况就变了。"
    
    AJ:"对的，你需要将你的护栏造成和马一样高"

如下，示例一个抽象的业务领域

![抽象的业务领域][bbb35a9b538c7cc1d2ca78a063892eb9.png]

**核心域**：它是整个业务领域的一部分，也是业务功能的主要促成因素。在战略层面上讲，企业应该在核心域上胜人一筹，给予最高的优先级、最资深的领域专家和最优秀的开发团队。

**支撑子域**：有时会创建或者购买某个限界上下文来支撑我们的业务。如果这样的限界上下文应对着业务的某些重要方面，但却不是核心，那么它便是一个支撑子域。它专注于业务的某个方面。

**通用子域**：一个子域被用于整个业务系统，整个子域别是通用子域。

支撑子域和通用子域并不是不重要，只是对他们的要求并不想核心域那么高。

**限界上下文**：主要是语言层面上的限界划分，是实现DDD的关键。一个限界上下文并不一定只包含在一个子域中。限的意思就是划分、规定，界就是界限、或者一个边界，上下文就是业务的整个流程。限界上下文定义了领域模型的边界，目的是清理子域，然后区分子域哪些是核心域、支撑子域和通用子域

> 战略设计为什么重要

很多开发者将关注点放在了实体和值对象上，从而缺少了广阔IDE视野。将不同的核心概念杂揉在一起，导致他们将两个模型构成了一个。如下所示：  
(不了解基本的战略设计，导致在协作模型中产生了不相匹配的概念，虚线是问题所在)

![错误DDD][DDD]

Q：是不是因为用户(user)和权限(permission)与协作概念存在着紧密的耦合？

A：资深开发指出：问题不单单在于耦合，到最后，论坛、讨论、日历和日历条目都会在一定程度上与协作人员发生耦合，这是事实。问题出在我们使用的语言，问题在于论坛和讨论等概念与错误的语言概念耦合起来了。用户和权限与协作活动没有任何关系，并且与协作的通用语言也风牛马不相及。用户和权限是与身份(identity)和访问(access)相关概念，即是与安全(security)相关的。在协作上下文中出现的每一种概念都必须与协作存在语言层面上的关联。而上图中没有。

通过增加角色这一协作上下文可以明确业务指向。  
![错误DDD][DDD 1]

> 如何命名限界上下文?

上文中用到的‘协作上下文’是通过“模型 + 上下文”这种方式来命名限界上下文的。表明它是包含有协作领域对象的限界上下文。

> 现实世界中的领域和子域

领域中还同时存在问题空间和解决方案空间

问题空间

我们思考的是业务所面临的挑战。对问题空间的开发将产生一个新的核心域。对问题空间的评估应该同时考虑已有子域和额外所需子域。因此，问题空间是核心域和其他子域的组合。问题空间中的子域常常随着项目的不同而不同，他们各自关注当前的业务问题。

解决方案空间

思考如何实现软件以解决这些业务挑战。包含一个或多个限界上下文，即一组特定的软件模型。这是因为限界上下文即是一个特定的解决方案。它通过软件的方式来实现解决方案。

对于问题空间的评估是有益于理解解决方案空间的。解决方案空间在很大程度上受到现有系统和技术的影响。

--------------------

下图是一个ERP系统的领域模型(只显示了特定问题空间的子域，并不是整个领域)  
![ERP领域][ERP]

我们应该根据分离的限界上下文仔细地思考一下问题：

*  有哪些软件资产是已经存在的，他们可以重用么？
 *  哪些资产是需要创建的，或者从别处获得？
 *  这些资产是如何集成在一起的？
 *  还需要什么样的集成？
 *  假设已经有了现有资产和那些需要被创建的资产，我们还需要做些什么？
 *  核心域和那些支撑项目的成功几率如何？会不会出现由于其中一个失败而导致整个项目失败的可能？
 *  在哪些地方我们使用了完全不同的术语？
 *  衔接上下文之间在哪些地方存在概念重叠？
 *  这些重叠的概念在不同的限界上下文之间是如何映射和翻译的？
 *  哪些限界上下文包含了核心域中的概念，其中使用了那些战术模式。

记住，开发核心域的解决方案是一种关键性的业务投入。

[https_www.deathearth.com_1242.html]: https://www.deathearth.com/1242.html
[d3067a7b88854fb0ef3edbbef69fdcf1.png]: /images/20221123/b5e44529c04c433d998483474a4580c3.png
[bbb35a9b538c7cc1d2ca78a063892eb9.png]: /images/20221123/db420dbd19ae45c69b70bb58fce3cd00.png
[DDD]: /images/20221123/f918e0255fa140a4a7e216aa4c59dc28.png
[DDD 1]: /images/20221123/f2e1e2e59f5a4ee2aef5560707507a87.png
[ERP]: /images/20221123/5ff45ce367074ebb93e7fe879a06df1d.png