限界上下文

限界上下文的

含义：用一个清晰可见的边界（Bounded）将这个上下文（Context）勾勒出来

Context 表现了业务流程的场景片段

上下文（Context）其实是动态的业务流程被边界（Bounded）静态切分的产物。

 

上下文（Context）是业务目标，

限界（Bounded）则是保护和隔离上下文的边界，

避免业务目标的不单一而带来的混乱与概念的不一致。

 

限界上下文的价值：

 

• 领域逻辑层面：限界上下文确定了领域模型的业务边界，维护了模型的完整性与一致性，从而降低系统的业务复杂度。

• 团队合作层面：限界上下文确定了开发团队的工作边界，建立了团队之间的合作模式，避免团队之间的沟通变得混乱，从而降低系统的管理复杂度。

• 技术实现层面：限界上下文确定了系统架构的应用边界，保证了系统层和上下文领域层各自的一致性，建立了上下文之间的集成方式，从而降低系统的技术复杂度。

 

引入限界上下文的目的：

不在于如何划分边界，而在于如何控制边界。

 

 

将大领域模型根据应用程序的业务需要“切割”成一系列较小的模型是非常重要

 

限界上下文是“分而治之”架构原则的体现，我们引入它的目的其实为了控制（应对）软件的复杂度

 

限界上下文看做是一个“自治”的单元：

​

 

1 最小完备（自身的职责 不需要与其他上下文相耦合）

是实现“自治”的基本条件。所谓“完备”，是指自治单元履行的职责是完整的，无需针对自己的信息去求助别的自治单元，这就避免了不必要的依赖关系 减少了变化的可能

 

2 自我履行（判断 职责是术语本单元 还是别的上下文所在单元 划分边界） 判断行为是否应该由其履行

意味着由自治单元自身决定要做什么。从拟人的角度来思考，就是这些自治单元能够对外部请求做出符合自身利益的明智判断，是否应该履行该职责，由限界上下文拥有的信息来决定。例如，可以站在自治单元的角度去思考：“如果我拥有了这些信息，我究竟应该履行哪些职责？”这些职责属于当前上下文的活动范围，一旦超出，就该毫不犹豫地将不属于该范围的请求转交给别的上下文。

例如，在当订单上下文履行了验证订单的职责之后，需要执行支付活动时，由于与支付相关的业务行为要操作的信息已经超出了订单上下文的范畴，就应该将该职责转移到支付上下文。

 

3 稳定空间 通过隐藏细节和开放抽象接口来封装变化

指的是减少外界变化对限界上下文内部的影响

划分自治空间，需要找到限界上下文之间的间隙处，然后依势而为，沿着间隙方向顺势划分，而所谓“间隙”，其实就是依赖最为薄弱之处。

 

例如，在电商系统中，管理商品上架、下架与评价商品都与商品直接相关，但显然评价商品与商品的依赖关系更弱。倘若需要分解限界上下文，保证上下文的稳定性，就可以将评价商品的职责从商品上下文中分离出去，但却不能分离商品上架和下架功能。

 

4 独立进化 约束接口的规范与版本

指的是减少限界上下文的变化对外界的影响。

稳定空间寓意下游限界上下文，无论上游怎么变，我自岿然不动；

独立进化寓意上游限界上下文，无论下游有多少，我凌寒独自开

实现：

要做到独立进化，就必须保证对外公开接口的稳定性，因为这些接口往往被众多消费者使用，一旦修改，就会牵一发而动全身。一个独立进化的限界上下文，需要接口设计良好，符合标准规范，并在版本上考虑了兼容与演化