DDD中BoundedContext视为限制上下文更好

22-01-03 banq
“We often fall into the trap of thinking of a boundary as something that separates one thing from another. We should rather think of a boundary as something that constitutes that which is bounded. This shift will help us to see the boundary as something enabling”—Paul Cilliers

“我们经常陷入这样一个陷阱:将边界这个概念看成是用来是将一件事与另一件事化分开,(比如划清界线,划分边界,分割线,边界线,领域边界)

但是,我们更应该将边界视为有限构成事物的一个事物。这种转变将帮助我们将边界视为一种赋能”——Paul Cilliers

banq:边界也是一个事物,这个事物是一种构建事物,如同设计模式中的工厂模式或builder构建者模式,工厂对象或builder对象是一个专门的用来构建的对象事物,这种构建的能力是有限的,不是无限的,有限是指空间或时间上的有限,有界,有起点和终点,有生命周期,有作用域的。

因此,bounded context的bounded如果翻译成“有限”这个词可能更好,“界限”或“有界”都是一种静态边界线的意思,而“有限”则包含动态上构建时是有限的意思,不是源源不断的构建,源源不断无限的构建是流stream。

 

综合理解

DDD中战略基础概念:

  • Domain = Boundary :领域 等于边界
  • BoundedContext @ UL :BC来自于或位于无所不在通用语言UL
  • Aggregates *emerges* from BC:聚合是从BC中"涌现"出来的一种关系体。

领域的边界是固定的,能比较长的生命周期内存在,静态的,类似全局静态变量;而上下文的边界则不是静止的,可能会动态模糊泄露,生命周期比较短和模糊,甚至一段时间内相互穿插,类似作用域概念。

BC上下文只有当被制成构建时才体现边界、有限或界限,正如黑人 白人出生时是有皮肤的区别界线,但是出生以后的边界就可能模糊了,人人平等了,都公平参与竞争,英雄就不问出处了,但是出处出身是有区别的,是我们设计时关注点。

BC上下文的出处是来自通用语言UL的,从UL中有限地发现构建制成了一些上下文,这样的上下文诞生之初肯定是有边界的,但是,我们不能认为上下文就永远被这个边界限制住了,随着时间发展,上下文之间的边界可能会模糊,但只要构建时是有限地构建制成了即可。

将关注点从永恒边界转移到BC诞生之初,这样做的好处是:

可以将BC就可以看成一种赋能,来自通用语言的赋能,

BC就在DDD战略设计和战术设计之间架起了一座桥梁,

赋能者(通用语言)可以通过BC赋能给战术设计中的聚合、实体、值对象等概念,也就是说,我们可以从UL中挖掘或通过暗喻、隐喻等方式赋能战术设计概念,典型案例见:通过语言的暗喻发现隐藏的DDD模型 - verraes

  

“限制”比“有限”更好

补充更正:Bounded Context翻译成“限制上下文”更准确,“限制”表示有成了某个上下文。

之前认为“有限”比“有界”或“界限”更恰当,因为表示赋能的能力边界,“有限”这个词语并没有体现“制成或构建”这个创建动作的含义,例如工厂模式的“工厂”包含了一种“生产”这个动作含义,因此,“限制”比“有限”更恰当。

   

构造与解构

当我们从构建这个角度看问题时,DDD可以划分两个大部分:

  • DDD战略设计=构造
  • DDD战术设计=解构

两者之间的桥梁是BC,战略设计是从现实业务中构造一个领域模型,这种附带有BC的领域模型进入战术阶段被却分解成如聚合或实体或值对象等。

但是现实中很容易发生将两个阶段割裂的情况,这也是过去OOA和OOD两阶段割裂的弊病。

如果将BC看成一种赋能,这样对聚合或实体的任何结构修改都必须考虑到BC,这样才能将业务逻辑和代码紧紧融合浑然一体,正如将算法逻辑与代码融合一样。

(业务领域Domain =>赋能或驱动=> 软件设计Design) = DDD

 

2
猜你喜欢