Being Agile！领域驱动设计的思考题-京东云开发者社区

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

#### 主编的话：

对于物流集团的研发小哥来说，第一次大规模的对技术的学习交流是4年前的设计模式，那一次涌现出来的新星，现在有好几位已然是三级部门的负责人；第二次是3年前数据库技术，最近这次DDD的学习加上去年架构部组织那次活动，可以合称为第三次。
DDD的引入的背后是对研发在流程复杂、变更多的业务背景下的更突破的探索，不在拘泥于代码层面，更深向业务领域。

DDD的起源是2004年Eric Evans 发表《领域驱动设计——软件核心复杂性应对之道》（Domain-Driven Design –Tackling Complexity in the Heart of Software）；近几年在大型传统IT企业和互联网公司应用都很热，前者在银行、航空等企业均有不错的应用；后者的使用的成功案例鲜有听说；我在网上找到一篇美团外卖的同学写的文章，倒是比较清楚，有感兴趣的同学可以自行搜一下。

DDD是思想也是一套方法论；对于大型的业务系统来说，开发人员需要了解业务知识，才能进行开发；在对业务知识梳理的过程中，形成领域知识，根据领域知识来一步步驱动软件设计。这是DDD为何备受推崇又很难推行的一部分原因（我们有多少时间花在梳理业务与提炼业务模型上）。

我们应几个二级部门要求，他们在实践DDD时，遇到痛点和瓶颈；我们邀请了国内最有实力的DDD实战老师，开展了一次DDD的实战进阶课程。为了保障学习的效果，在课前对DDD的一些概念进行了澄清，此次分享的就是课前业务架构师周老师梳理的内容。

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

### DDD限界上下文的思考

#### 关于限界上下文的思考
#### 1、怎样理解限界上下文的自治？
**答：自治的4给维度：**
- 最小完备（只了解该知道的）：履行属于自己的业务能力时，拥有的领域知识是完整的，无需针对自己的信息去求助别的限界上下文。最小是强调不必拥有多余的知识。
- 自我履行（有所为有所不为）：自己的领域知识履行职责只，不越界，企图重用别人的领域模型，甚至绕过限界上下文直接访问不属于它的数据。
- 稳定空间（不被别人影响）：指的是减少外界变化对限界上下文内部的影响，就是要解除或降低对外部软件元素的依赖，包括必须访问的环境资源如数据库、文件、消息队列或者其他限界上下文。
- 独立进化（不影响别人）：是减少当限界上下文内部变化对外界产生的影响，对外公开稳定的接口，而将内部领域模型的变化封装在限界上下文的内部

<center>![](//img1.jcloudcs.com/developer.jdcloud.com/cb8b09cf-e988-4a0c-9e0d-be49fd8b074e20210115142026.png)</center>

#### 2、关于限界上下文和应用的关系，一个应用可以包含一个上下文或者多个上下文，但是上下文不能跨应用，你认为合理吗？为什么？
**答：合理。**
一个单体系统实际上是一个应用，里面包含一个或者多个上下文，如果需要，我们把其中的一个上线文单独部署为一个应用，这是常见场景；所谓的上下文映射也是从应用角度来定义的。如果让上下文跨应用，不但事务处理复杂，关键上下文的本质特征“自治性”被削弱了，又要在上下文内部思考“子上下文”的映射关系。综上，上下文不跨应用是合理的。

两个上下文如果是同一个应用，互相之间有本地的应用服务调用，如果两个上下文各自单独应用，走远程服务进行调用。
#### 3、不同上下文领域模型不应重复，但是在供应链系统中，商品限界上下文、运输限界上下文与库存限界上下文的领域模型都定义了Product，你认为这样合理吗，为什么？
**答：这种情况要具体分析。**
如果从商品上下文作为Product的源头，定义其基本属性，而运输上下文的商品只是关心运输语境下商品的特征的话，如长、宽、高、重，运输归类等特征的话，这样做是合理的，只是运输上下文的ProductID来自于商品上下文ProductID。

其实一个概念在不同上下文存在，但是关注点不同，这样做可以更好的保证上下文的自治性，“最小完备”吗，有了必备的知识，不必事事求人。
#### 4、让限界上下文尽量少的被外部影响，是通过何种方式实现的？
**答：**实际上这个问题是上下文“自治”特征之一关于稳定空间的，就是“不被被人影响”，是通过防腐层ACL的方式来实现，在菱形对称架构中是通过南向网关的端口层定义接口，适配器层实现来接口。
##### 5、技术复杂度和业务复杂度的分离是如何在架构上体现的？
**答：**通过整洁架构的分层思想来体现，六边形架构中，最核心的是领域层，体现领域级业务复杂度，再向外的应用服务层，体现用例价值，二者都不依赖任何具体的技术实现，体现技术复杂度的基础设施层是向内依赖应用服务层和领域层。在菱形对称架构上，北向网关的远程服务层，南向网关的适配器层体现了技术复杂度，它们向内依赖了应用服务层和领域层，也体现了技术复杂度和业务复杂度的分离。

WMS6.0项目中对外暴露的jsf服务， rest都是应用服务API的不同技术实现方式，内部的external和资源库存定义为接口，通过基础设施层来实现。
#### 6、传统的分层架构，六边型架构和菱形对称架构的区别是什么？
**答：**分层架构：是自顶向下的层次关系，UI》应用层》领域层》数据访问层，一种水平的层次划分，依赖方向也自顶向下，不强调领域层的核心定位。

六边形架构：符合整洁架构的思想，把领域逻辑作为核心，从外向内的依赖，从外向内是基础设施层》应用层》领域层，强调了领域层的核心地位，把持久化是实现放在最外面的基础设施层。

菱形对称架构：本质上是和六边型架构是一样的，都是让领域层处于核心地位，但是做了些简化调整，看上去更符合人的自然思维，开发友好。分为领域层，北上网关（入）和出南下网关（出），入的时候原本是从外向内不需要调整依赖方向，出的时候需要调整依赖方向，让南下网关的适配器层依赖端口层，如图：

<center>![](//img1.jcloudcs.com/developer.jdcloud.com/0e9a1e9e-6873-49d9-8839-e7e297d3428c20210115142249.png)</center>

#### 7、举例说明从业务维度、管理维度、技术维度划分限界上下文？
**答：**业务维度是我们思考划分限界上下文的根本标准，可理解为对业务的纵向拆分，比如仓储系统拆分“出库、入库、在库”三个上下文；但是出库随着业务的发展细化，团队增加到近40人，管理效率下降， “2PTsT”原理发挥作用，降低团队规模，于是把出库上下文拆分为“出库计划、拣货、复核打包、发货”上下文，各个上下文独立团队；后来发现“出库计划”上下文的“任务分配” 服务智能化要求提升，需要运筹学，大数据等算法，甚至服务器要GPU的，对技术的要求不一样，单独设计部署更有利，于是“任务分配”上下文被独立出来，2个人专门搞。

#### 8、限界上下文是业务语境的上下文，和团队边界没有关系，这样说对吗，为什么？
**答：不对**。业务语境虽然是划分上下文的最核心因素，但是不是唯一因素，团队有效沟通的边界也是应该考虑的因素，当一个上下文的团队规模过大时，需要把上下文拆小来适应减小团队规模到合理边界。从这个角度看，上下文会随着业务发展而动态变化。
#### 9、对照下图总结出限界上下文和模块的区别？
<center>![](//img1.jcloudcs.com/developer.jdcloud.com/7fbdcd44-7468-45b4-aed8-74373445edfe20210115142427.png)</center>

<center>![](//img1.jcloudcs.com/developer.jdcloud.com/421c7aad-5650-45dd-af67-ecce8cb90be420210115142438.png)</center>

答：模块可以不同层进行定义，可以业务维度，也可以是技术维度，是一种单纯的逻辑区分，没有特别多的含义。限界上下文是DDD独有的概念，是一种纵向的拆分，强调自治性，拥有自己的数据；内部会分层，强调技术复杂度和业务复杂度的分离。

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者：中台技术部 周吉鑫