专栏首页斑斓初窥Bounded Context

初窥Bounded Context

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是一个显式的边界,领域模型便存在于这个边界之内。领域模型把通用语言表达成软件模型。创建边界的原因在于,每一个模型概念,包括它的属性和操作,在边界之内都具有特殊的含义。

▲ 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),作者:张逸

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2015-03-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 当DDD遇上微服务

    DDD与微服务是可以相通的,其关键在于Bounded Context。 分布式系统的定义 在谈论这个之前,我们需要就什么是分布式系统达成一致。在我看来,判断一个...

    张逸
  • 【第三格】如何实现领域驱动设计

    从Eric Evans写下经典名著Domain-Driven Design: Tackling Complexity in the Heart of Softw...

    张逸
  • 基于Scala Trait的设计模式

    在《作为Scala语法糖的设计模式》中,我重点介绍了那些已经融入Scala语法的设计模式。今天要介绍的两个设计模式,则主要与Scala的trait有关。 Dec...

    张逸
  • Django进阶-8-ORM多对多

    Django ORM 中一个类名对应一张表,要想操作表就 models.类 直接操作那张表。如果使用 ManyToManyField 字段生成“第三张”关系表,...

    小团子
  • 原生JS | 当兔子遇到鸡

    HTML5学堂-码匠:当兔子遇到鸡,会怎样呢?先别急,看个小视频~ 视频内容 当兔子遇到鸡 —— 不要害怕和别人不一样,在这个世界上,你就是独一无二的自己! 不...

    HTML5学堂
  • python2 UnicodeDecodeError: 'ascii' codec can't decode byte 0xce in position 7: ordinal not in range

    python在安装时,默认的编码是ascii,当程序中出现非ascii编码时,python的处理常常会报这样的错UnicodeDecodeError: 'asc...

    用户1214487
  • 第一个IronPython程序(之二)

    万物皆对象,意思是 IronPython 函数有属性, 并且这些属性在运行时是可用的。在 IronPython(Python) 中, 函数同其它东西一样也是对象...

    张善友
  • 针对B端产品,如何顺利开展workshop?

    各位B端产品/需求分析的同学一定对workshop这个名词不陌生,它的中文名是需求访谈会。个人对C端产品不熟,本文也仅就B端产品的访谈聊一聊个人经验。本文适合0...

    物流IT圈
  • Web端服务器推送技术

    传统的本地客户端可以基于Socket套接字与服务器建立持久连接,服务器能实时地将更新的信息传送到客户端,而无须客户端发出请求。但HTTP属于无状态连接,即每次请...

    江米小枣
  • HTML <form> 标签的 enctype 属性

    默认地,表单数据会编码为 "application/x-www-form-urlencoded"。就是说,在发送到服务器之前,所有字符都会进行编码(空格转换为 ...

    大道七哥

扫码关注云+社区

领取腾讯云代金券