初窥Bounded Context

简介: Bounded Context(限界上下文)是DDD中最难解释的原则,但或许也是最重要的原则。可以说,没有Bounded Context,就不能做DDD。本文就带领大家初探Bounded Context。

序言:  张逸者,70年代生人。软件开发生涯经历了从程序员、项目经理、测试经理、开发部长、技术总监到架构师的一个循环,而后程序员,现在是创业公司CTO。三大爱好是开发、写作与阅读。著译作包括《软件设计精要与模式》、《WCF服务编程》、《Java设计模式》与《恰如其分的软件架构》。张逸现居于锦官城,与中生代诸君多有往来。张君于设计模式、软件架构、DDD以及clean code等方面研究尤深。开公众号而不刷粉,则多数文字并不显于街市,中生代编辑之以飨读者,使佳作流传,善莫大焉!


Bounded Context(限界上下文)是DDD中最难解释的原则,但或许也是最重要的原则。可以说,没有Bounded Context,就不能做DDD。
Bounded Context是领域驱动设计中战略设计的重要组成部分,一定程度上决定了系统的逻辑架构以及集成方式。基于康威定律,Bounded Context的划分也可能会影响项目的组织结构。DDD社区将Bounded Context定义为:
应该显式地定义某个模型所应用的上下文。还应该在团队组织、应用中特定部分的使用以及像代码库和数据库模式等物理表现等方面显式地设定边界。要保持边界中模型的严格一致,而不要受外界问题的影响与干扰。
这段话表达了一个关键概念是“边界”,这与软件设计中“分而治之”的思想有关。通过为领域模型划定合理的边界,就可以降低设计与开发的复杂度。此外,边界还能够划分知识的层次,例如对外而言,可以只保障暴露在边界外接口的一致性,以及关注它们之间的集成方式。边界之内则自成一体,可以独立演化,甚至可以包容一到多个遗留模块。
正是因为Bounded Context带来的隔离性,Juelin Lerman才认为:“把一个将大量的类放在一个上下文中的独立模型分解为多个较小的模型是有好处的。Bounded Context创建的模型较小,而且内聚性更高,同时维持了模型之间的边界。”
于是,Bounded Context在DDD中的重要性也就凸显,DDD社区逐渐认识到了这一点。Mike在文章《DDD: The Bounded Context Explained》中认为:Bounded Context是DDD中最难解释的原则,但或许也是最重要的原则。可以说,没有BC,就不能做DDD。在了解Aggregate Root、Aggregate、Entity等概念之前,需要先了解BC。
重要性凸显了,然而问题也随之而来。几个问题如乌云一般盘旋在我的头顶,驱使我思考Bounded Context的本质。问题如下:
  • 如何确定或划分Bounded Context?
  • Bounded Context是否具有层次?
  • Bounded Context划分的边界是逻辑的,还是物理的?
  • Bounded Context之间的通信方式?
为了解决如上问题,我查阅了许多书籍与资料,也从项目实践中去探索。在回答这些问题之前,我先抛出一些概念知识。
Vaughn Vernon的大作Implementing Domain-Driven Design解释了他对Bounded Context的理解:
Bounded Context是一个显式的边界,领域模型便存在于这个边界之内。领域模型把通用语言表达成软件模型。创建边界的原因在于,每一个模型概念,包括它的属性和操作,在边界之内都具有特殊的含义。
                                                       2b36a1e4adc853172c41df0fdf0e7d141a735763
                                                                     ▲ Vaughn Vernon | 实现领域驱动设计
Mike同样认为一个上下文意味着一个专有的职责,而且BC之间应该是解耦的,彼此并不知道。一个BC并不知道另一个BC的内部,但这两个BC都可以使用Common Objects(DTOs)来完成彼此之间的通信;或者使用专用的Adapter。

这里事实上谈到的是BC的设计原则,它与OO设计原则一脉相承。在文章《Bounded Contexts as a Strategic Pattern Beyond DDD》中,作者提到了开发者可以应用GRASP原则来设计Bounded Context,尤其是低耦合、高内聚与信息专家模式。

就在这篇文章中,作者还提到了BC与Domain之间的关系:
Bounded Context的一个显著特点在于它与Domain匹配。因此,它体现的是高层的抽象机制。Bounded Context并非编程语言或框架的产出工件,而是体现了人们对领域思考的本质。
结合这些知识,我们可以这样描述Bounded Context的特征:
  • BC是模型概念,与实现无关,是高层的抽象机制
  • 具有自己独立的边界,是自治的,遵循高内聚、松耦合
  • BC之间的关系决定它们之间的协作与通信方式
  • 它与Domain应为一一对应关系
  • 一个上下文意味着一个专有的职责

要驱动出Bounded Context,毫无疑问需要与领域专家交流,通过提炼统一语言,来创建BC。然而,统一语言的建立固然有助于进一步深化和细化领域模型,但并不能直接帮助我们创建BC。从Bounded Context到Context Map的设计过程并非单向的,而是一个螺旋演进的过程。


相关文章阅读:可视化与领域驱动设计


本文作者 张逸

转载自 微信公众号 逸言 YiYan_OneWord


目录
相关文章
|
5月前
|
设计模式 安全 Java
程序与技术分享:Context详解
程序与技术分享:Context详解
72 0
|
6月前
|
JavaScript 前端开发 中间件
【掰开揉碎】Redux 和 Context 到底怎么选
【掰开揉碎】Redux 和 Context 到底怎么选
136 0
|
6月前
|
Kubernetes 安全 容器
k8s学习-CKS真题-Context安全上下文
k8s学习-CKS真题-Context安全上下文
124 0
|
设计模式 安全 Java
重温Context
从程序的角度上来理解:Context是个抽象类,而Activity、Service、Application等都是该类的一个实现。
|
存储 监控 API
Activity初窥门径
上一节中我们对Activity一些基本的概念进行了了解,什么是Activity,Activity的生命周期,如何去启动一个Activity等,本节我们继续来学习Activity,前面也讲了一个App一般都是又多个Activity构成的,这就涉及到了多个Activity间数据传递的问题了,那么本节继续学习Activity的使用!另外关于传递集合,对象,数组,Bitmap的我们会在Intent那里进行讲解,这里只介绍如何传递基本数据!
|
消息中间件 JavaScript 小程序
Lombok 同时使用 @Data 和 @Builder 的巨坑,千万别乱用!
Lombok 同时使用 @Data 和 @Builder 的巨坑,千万别乱用!
|
Java 开发工具
Lombok 同时使用 @Data 和 @Builder 的巨坑,千万别乱用!(1)
Lombok 同时使用 @Data 和 @Builder 的巨坑,千万别乱用!
727 0
Lombok 同时使用 @Data 和 @Builder 的巨坑,千万别乱用!(1)
|
Java API
Lombok 同时使用 @Data 和 @Builder 的巨坑,千万别乱用!(2)
Lombok 同时使用 @Data 和 @Builder 的巨坑,千万别乱用!
231 0
Lombok 同时使用 @Data 和 @Builder 的巨坑,千万别乱用!(2)
|
监控 安全 Go
Go语言核心手册-11.context.Context
我们今天主要讨论的是context包中的函数和Context类型,该包中的函数都是用于产生新的Context类型值的,Context类型是一个可以帮助我们实现多goroutine 协作流程的同步工具,不但如此,我们还可以通过此类型的值传达撤销信号或传递数据。
103 0
Go语言核心手册-11.context.Context
|
XML 存储 Java
spring源码分析系列4:ApplicationContext研究
spring源码分析系列4:ApplicationContext研究
spring源码分析系列4:ApplicationContext研究