资讯专栏INFORMATION COLUMN

限界上下文(BC)是什么

JackJiang / 3438人阅读

摘要:翻译自有整理你问的限界上下文是什么特定模型的分隔适用性。限界上下文意味着责任是通过明确的边界来强制执行的举个例子过程约翰,公司的开发人员。每个组也是有限的上下文。

翻译自DDD - The Bounded Context Explained,有整理
你问的限界上下文(BC)是什么?

“特定模型的分隔适用性。限界上下文使团队成员能够清楚地分享对必须一致的内容以及可以独立开发的内容。”

看定义看懂了吗?

BC是最难解释的DDD原则之一,但它可能是最重要的,因为没有BC就不能做DDD。因此,您必须了解如何在实际获取根聚合,聚合,实体和值对象之前识别BC。

让我们再试一次:上下文意味着具体的责任。限界上下文意味着责任是通过明确的边界来强制执行的

举个例子 过程

约翰,X公司的开发人员。约翰在IT部门工作

丽塔,她是同一家公司的会计师。丽塔在会计部门工作

此时,IT部门是一个限界上下文,会计部门是另一个限界上下文

IT部门有责任处理公司中与IT相关的所有事务,而会计部门处理与会计相关的所有事务

约翰不会进入丽塔的办公室并修改工资单,而丽塔也不会去约翰的办公室并修改他的代码。

虽然他们可以这么做,但这将是一个丑闻。因为如果他们这样做,他们将超越他们的界限。

如果丽塔在会计软件(内部开发)中发现错误,她会致电IT部门处理。她不会启动Visual Studio并开始搞乱代码。这既不是她的责任同时她也不需要知道怎么做,即使她知道VS是约翰用来编写代码的程序(事实上,VS在会计师的计算机上将是一个非常奇怪的软件)

同样明智的是,工资单文件或发票在IT部门中是没有位置的。

当然,当约翰遇到涉及工资单的问题时,他要求丽塔调查一下。

两者都尊重彼此的界限,并根据自己的责任行事。

但IT部门本身分为两组:软件开发组和管理组。第一组实现功能并修复错误。第二组处理服务器。每个组也是有限的上下文。他们有自己的责任和明确的界限。 DBA不编写C#代码,约翰不会破坏服务器配置。每个人都按照自己的责任行事并在自己的范围内行事。

两者都有非常精确的责任,他们的界限非常明确。

小结

所以,IT部门是BC。约翰是其模型的一部分。
事实上,所有有意义的东西(开发人员,服务器等)都是BC的一部分,它应该在内部保持一致(开发人员应该编写软件而不是询问发票)。
这意味着丽塔在IT方面没有地位,她不应该处理与IT相关的任何事情。
丽塔是会计BC的一部分。她可能正在访问IT办公室,但她只是一个匆匆过客,她对该部门毫无意义,没有人希望她编写代码或充当开发人员。约翰可能喜欢丽塔,并花了一些时间在她的办公室,但这并不能使约翰成为一名会计师。

不同BC之间的“合作” BC与BC的关系

我们可以看到,在一定程度上,BC是自治的,它们不重叠。此外,如果来自一个BC(X)的对象转到其他BC(Y),它并不意味着它现在是后者的一部分,它仅被视为一个对Y没有意义的简单对象。所以它们几乎是独立的,那么他们如何一起工作?

不同BC之间该如何合作 例子说明

登场新人物 -> 安德鲁(IT部门经理)

按照例子来说,当会计部门必须和IT部门合作的时候该如何做?

他们通过与合适的人交谈来做到这一点。

当丽塔需要一个新的软件功能时,她可以告诉约翰,但约翰的经理(安德鲁)最终决定是否添加,以及将添加哪些功能。

当你想要新功能甚至修复一些错误时,是需要与安德鲁交流的。安德鲁是IT经理,他告诉约翰(或IT的其他任何人)下一步该做什么。

丽塔不能忽视安德鲁,因为这是IT部门的规则:安德鲁做决定。你必须按照安德鲁想要的方式提出你的想法,否则他们会被拒绝。当要求对IT不符合方式且没有意义的时候,要求会自动被拒绝。

安德鲁是IT BC的反腐败层,没有什么决定能够跳过他,它适合于IT部门的内部组织。

类比到代码

这些例子很简单,但我们的代码呢?我们确实希望我们的BC能够解耦,所以BC1不应该知道BC2。好吧,这个想法是一个BC不应该知道其他BC的内部,这两个可以使用公共对象(DTO)直接将消息传递给另一个或者是专门的适配器,它知道如何与两个BC通信。虽然通过域事件(基本上是更高级别使用的观察者模式)的首选方法。

结束语

哇,很长的帖子,但我希望你现在对一个有限的背景有一个非常明确的理解。以下是常见有界上下文的一些示例:应用程序本身,UI层,域层以及它们的最小BC:对象,任何对象。

参考

DDD - The Bounded Context Explained

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/28078.html

相关文章

  • 领域驱动设计战术模式--领域事件

    摘要:将领域中所发生的活动建模成一系列离散事件。领域事件是领域模型的组成部分,表示领域中所发生的事情。创建领域事件事件命名在建模领域事件时,我们应该根据限界上下文中的通用语言来命名事件。 使用领域事件来捕获发生在领域中的一些事情。 领域驱动实践者发现他们可以通过了解更多发生在问题域中的事件,来更好的理解问题域。这些事件,就是领域事件,主要是与领域专家一起进行知识提炼环节中获得。 领域事件,可...

    wzyplus 评论0 收藏0
  • 基本算法思想:递归+分治+动态规划+贪心+回溯+分支限界

    摘要:代码实现见下面评论对应代码动态规划基本思想和分治法基本思想有共同的地方,不同的是子问题往往不是独立的,有事母问题要借助子问题的解来判断,因此把已经计算好的问题记录在表格中,后续如果需要查询一下,可以避免重复计算,这是动态规划的基本思想。 作者:心叶时间:2018-05-01 19:28 本文对应github地址:https://github.com/yelloxing/... 以上实现...

    EscapedDog 评论0 收藏0
  • 《微服务设计》读书笔记(关于微服务的一点想法)

    摘要:而微服务将这个理念应用在独立的服务上。微服务对比与原来的单体应用,有它的优势,如服务的自治性增强但同时也会带来一些其他问题,如性能复杂度等问题。想要使用微服务,首先是要清楚哪些业务或者功能应该成为单独的服务。其次,考虑业务极有可能的变化。 1、在学习软件构造、设计相关知识时,大家应该有学习到内聚性的概念:即把因相同原因而变化的东西聚合到一起,而把因不同原因而变化的东西分离开来。而 微服...

    lpjustdoit 评论0 收藏0
  • 校招社招必备核心前端面试问题与详细解答

    摘要:本文总结了前端老司机经常问题的一些问题并结合个人总结给出了比较详尽的答案。网易阿里腾讯校招社招必备知识点。此外还有网络线程,定时器任务线程,文件系统处理线程等等。线程核心是引擎。主线程和工作线程之间的通知机制叫做事件循环。 showImg(https://segmentfault.com/img/bVbu4aB?w=300&h=208); 本文总结了前端老司机经常问题的一些问题并结合个...

    DevTalking 评论0 收藏0

发表评论

0条评论

JackJiang

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<