限界上下文 2021-09-04 程序之旅 暂无评论 647 次阅读 ## 限界上下文 在软件设计中，复杂系统中包含了那么多的场景，每个场景都包含了那么多的邻域对象，并且每个邻域对象中还存在那么多的复杂关系，我们对系统的领域模型该如何设计？ ### 问题域和限界上下文 首先，我们应该将整个系统划分成许多相对独立的业务场景，在一个个的业务场景中进行邻域分析与建模，这样的业务场景称之为“问题子域”，简称“子域”。 邻域驱动核心的设计思想--将对软件的分析与设计还原到真实世界中，真实世界的业务与问题叫作“问题域”，业务规则与知识叫“业务邻域知识”。 例如： - 电商网站的“问题域”：人们如何进行在线购物，购物的流程是怎么样的 - 在线订餐系统的“问题域”：人们如何在线订餐，饭店如何在线接单，系统是如何派送骑士去配送的 对于这些问题域，我们需要对其进行分而治之的方式来转换为“问题子域”。例如： - 电商网站--用户选购、下单、支付、物流等多个子域 - 在线订餐系统--用户下单、饭店接单、骑士派送等子域 一个复杂系统的领域设计，是以子域为中心进行领域建模，绘制出一张张的领域模型设计，称之为“限界上下文”(Context Bounds, CB)。 > 限界上下文的设计符合高质量软件设计的单一职责原则，即每个限界上下文中实现的都是软件变化同一个原因的业务。 在用户下单的过程中，用户信息的读取是否也应该在“用户下单”这个限界上下文中实现呢？答案是否定的，因为读取用户信息，不是下单的职责，当用户下单发生变更的时候，用户信息不一定变，用户信息变的时候，用户下单也不一定变，他们是用户下单的两个原因。因此用户信息的操作交给“用户信息管理”限界上下文。像“用户下单”与“用户信息管理”这样的相互关系，我们称之为“上下文地图”(Context Map)--限界上下文之间的相互关系。 > 所谓限界上下文内的高内聚，也就是每个限界上下文内实现的功能都是软件变化的同一个`原因`的代码。因为这个原因的变化才需要修改这个限界上下文，而不是这个原因的变化，就不需要修改这个限界上下文。正因为限界上下文的特性，许多团队就以限界上下文作为`微服务拆分`的原则，即每个限界上下文对应一个微服务。 使用限界上下文作为微服务拆分的原则，作用与好处 - 很好地将每次的需求变更，快速落到某个微服务中变更 - 实现低成本维护与快速交付，快速适应市场变化，提升企业竞争力 ### 限界上下文之间低耦合 > 限界上下文通过限界上下文地图相互调用时，通过接口进行调用  如上左图所示，模块 A 有用到模块 B ，那么模块 A 就模块 B 存在了耦合，这个时候所有复用模块 A 的地方，都必须有模块 B，否则复用模块 A 就会报错。如果模块 B 依赖 C 与 D，那么模块 A 还需要依赖模块 C 与 D，使用模块 A 的成本就变成特别高昂。 如上右图所示，模块 A 并没有依赖模块 B，但是模块 A 依赖了接口 B\`,模块 B 实现了接口 B\`,这样所有用到模块 A 的地方都不需要依赖模块 B，同理如果模块 A 需要调用模块 F 的，那么模块 F 就需要实现 B\`的接口。这样调用方与被调用方的耦合就被解开。  ### 微服务的困局  当多个微服务需要读取同一个表时，如上，当商品信息表别修改时，其他微服务都需要进行修改，并且所有的内容都需同时发布。微服务的优势不能发挥出来，使得维护的成本更高。这里有一个关键的问题在于，当多个微服务需要读取一个表时，也就意味着同一个软件变化`原因`，因商品信息而变更的代码，被分散到多个微服务中，当系统因为商品的原因而变化时，代码的修改自然分散到多个微服务，各微服务间不能形成高内聚。 ### 最佳实践是邻域模型 - 从 DDD 开始需求分析、邻域建模，逐渐建立起多个问题子域 - 将问题子域落实到限界上下文，它们之间的关联形成上下文地图 - 各子域落实到微服务贫血或充血模型的设计，从而在微服务之间根据上下文地图形成接口  ### 总结 微服务设计的困局是拆分->拆分的核心是“小而专”“高内聚”->破解微服务困局的关键是 DDD 打赏: 微信, 支付宝 标签: 领域模型, DDD 本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。
微信
支付宝