十年开发老司机，感悟DDD领域驱动设计的战略设计到底是什么？

r囧r小猫 2022-08-28 05:55 228阅读 0赞

模型设计，DDD 分两阶段，战略设计和战术设计。

# 战略设计 #

战略设计的子域、限界上下文和上下文映射图等概念大致分为：

*  业务划分  
    以区分不同业务，即划分识别出来的业务概念
 *  落地成解决方案  
    将划分出来的业务落地

# 业务概念的划分 #

首先需要明确：

## 问题是什么 ##

我们要解决的问题就是领域问题，相关概念如，子域、核心域、支撑域、通用域等。其实都是：如何分解问题。

## 如何解决 ##

领域（Domain）是一号位，对应待解决的问题。解决问题通常思路是分而治之，DDD就把一个大领域分解成若干小领域（子域（Subdomain））。

DDD首先要建立起一套通用语言，拥有一致的业务词汇表，它们对应模型。  
接着，要分类词汇，即把它们划分到不同子域。**关键就是分离关注点。**

比如，做个项目管理软件，就要有用户、项目、团队，不同人还要扮演不同角色。  
第一步，至少先分开身份管理、项目管理，因为关注点不同：

*  身份管理，关注用户身份信息，如用户名、密码
 *  项目管理，关注项目和团队等

这就有了俩子域：身份管理，项目管理。

若直接给结果，你可能会觉得很好理解。但划分出不同子域还是容易出问题的，因为有些概念不易区分。  
比如，用户应该怎么划分？放在身份管理是合适的，但项目管理也要用到呀！

根据单一职责原则，它给了我们一个重要思考维度，**变化从何而来**？  
不同角色的人关注不同变化，所以，虽然我们用的词都是“用户”，但想表达的含义其实不同，最好分开这些不同的含义，即分开不同角色：

*  身份管理中，它是“用户”
 *  项目管理中，就成了“项目成员”

# 业务概念的落地 #

DDD问题层面的概念已经阐述完毕。接下来，就是解决方案层面。

切分出的子域，怎样落实到代码？  
首先要解决的就是这些子域如何组织？

*  写一个程序把所有子域都放里面
 *  每个子域单独做个应用
 *  有一些在一起，有一些分开

这就引出DDD的

# 限界上下文（Bounded Context） #

限定了通用语言自由使用的边界，一旦出界，含义便无法保证。  
比如，同样是“订单”，不加限制，很难区分它在哪种场景。一旦定义了限界上下文，那交易上下文的“订单”和物流上下文的“订单”肯定不同。就是因为订单这个说法，在不同边界内，含义不同。

注意，子域和限界上下文不一定是一一对应的，可能在一个限界上下文中包含了多个子域，也可能在一个子域横跨了多个限界上下文。

限界上下文是在解决方案层面，所以，就可以把限界上下文看作一个独立系统。限界上下文与微服务的理念契合，每个限界上下文都可成为一个独立服务。

限界上下文是完全独立的，不会为了完成一个业务需求要跑到其他服务中去做很多事，这恰是很多微服务出问题的点，比如一个业务功能要调用很多其他系统功能。

有限界上下文，就可以把整个业务分解到不同的限界上下文中，但是，尽管我们拆分了系统，它们终究还是一个系统，免不了交互。  
比如：

*  一个用户下了订单，这是在订单上下文中完成的
 *  用户要去支付，这是在支付上下文中完成的

我们要通过某种途径让订单上下文的一些信息发送到支付上下文。所以，要有一种描述方式，描述不同限界上下文之间交互的方式-上下文映射图（Context Map）。  
DDD 给我们提供了一些描述这种交互的方式，比如：

*  合作关系（Partnership）
 *  共享内核（Shared Kernel）
 *  客户-供应商（Customer-Supplier）
 *  跟随者（Conformist）
 *  防腐层（Anticorruption Layer）  
    防腐层是最具防御性的一种关系，就是在外部模型和内部模型之间建立起一个翻译层，将外部模型转化为内部模型。但凡有可能，就要建立防腐层，将外部模型完全隔离开。
 *  开放主机服务（Open Host Service）
 *  发布语言（Published Language）
 *  各行其道（Separate Ways）
 *  大泥球（Big Ball of Mud）  
    要规避

这么多交互方式，主要是为让你在头脑中仔细辨认，看看限界上下文之间到底在以怎样的方式交互。

知道不同限界上下文之间交互方式后，不同交互方式就可落地为不同协议。  
常用协议如：REST API、RPC 或是 MQ， 按需选型即可。

在我们定义好不同的限界上下文，将它们之间的交互呈现出来之后，就得到了一张上下文映射图。  
上下文映射图是可以帮助我们理解系统的各个部分之间，是怎样进行交互的，建立全局性认知。

发表评论取消回复

表情：

评论列表（有 0 条评论，228人围观）

还没有评论，来说两句吧...

相关阅读

相关 DDD领域驱动设计

DDD领域驱动设计概述前言领域驱动设计（Domain Driven Design，简称DDD）是一种软件开发方法论，旨在帮助开发人员更好地理解业务需求，将业务需

拼搏现实的明天。/ 2024年03月16日 18:47/ 0 赞/ 291 阅读

相关 DDD领域驱动设计

目录概述软件开发和DDD区别建立领域知识通用语言模型驱动设计实体(Entit

曾经终败给现在/ 2023年02月24日 03:48/ 0 赞/ 208 阅读

相关 DDD领域驱动设计-什么是领域驱动设计

‘领域驱动设计’估计大部分人看了并不太理解，‘领域’是指建立了领域模型，‘设计’是指程序实现也就是程序编码。领域驱动设计可以理解为：严格按照模型来编写代码，能够使代码更好地

Dear 丶/ 2022年11月18日 01:50/ 0 赞/ 478 阅读

相关 DDD领域驱动设计

DDD领域驱动设计 1. 领域驱动设计 1.1 领域驱动概述 1.2 领域驱动优点 1.3 DDD解决复杂度的方式 2

阳光穿透心脏的1/2处/ 2022年10月18日 01:35/ 0 赞/ 732 阅读

相关 DDD 领域驱动设计

目录 ddd分层 server领域划分实体类 ddd，domain-driven desig

浅浅的花香味﹌/ 2022年10月11日 01:18/ 0 赞/ 442 阅读

相关浅析DDD(领域驱动设计)

> 最近在做一些微服务相关的设计，内容包括服务的划分，Restful API的设计等。其中比较棘手的就是Service的职责划分：如何抽象具有统一业务范畴的Model，使其模块

向右看齐/ 2022年09月29日 12:55/ 0 赞/ 414 阅读

相关领域驱动设计（DDD）：领域接口化设计

点击关注公众号，利用碎片时间学习![0d585d6a52aac94108f91bac86a26eb0.png][] 把服务对象（service）和资源库对象（reposito

不念不忘少年蓝@/ 2022年09月11日 02:20/ 0 赞/ 397 阅读

相关十年开发老司机，感悟DDD领域驱动设计的战略设计到底是什么？

模型设计，DDD 分两阶段，战略设计和战术设计。战略设计战略设计的子域、限界上下文和上下文映射图等概念大致分为：业务划分以区分不同业务，即划

r囧r小猫/ 2022年08月28日 05:55/ 0 赞/ 229 阅读

相关 DDD（领域驱动设计）

基本概念：　　领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tac

﹏ヽ暗。殇╰゛Y/ 2021年12月17日 04:41/ 0 赞/ 681 阅读

相关【吐血推荐】什么是领域驱动设计？DDD？

> 本文公众号来源：我没有三颗心脏作者：我没有三颗心脏 > > > > > 本文作者是我在大三认识一个朋友，以前就经常看他的文章。这次他写了一篇《DDD》（虽然

桃扇骨/ 2021年09月30日 23:32/ 0 赞/ 597 阅读