wincc上下文不存在或无效是_讲真，别再拿着聚合寻找限界上下文了

聚合分组法和它的问题

在事件风暴工作坊中，常用的划分限界上下文的方法是：

对前一步（事件风暴）产生的聚合进行分组，通过业务的内聚性和关联度划分边界，结合限界上下文的定义进行判断，并给出上下文名称。
[服务化设计阶段路径方案]

我将其称之为“聚合分组法”。然而面对一堆聚合，要得出一套合理的分组是非常困难的：

1. “相关性”全凭经验
   相关性是一个过于抽象的规则，非常依赖经验。
   举个例子。在一个活动运营系统中，有“注册奖励活动”、“注册奖励规则”、“任务奖励活动”、“任务奖励规则”等概念。是把所有的“活动”分为一组，所有“规则”分为一组，还是把“注册”相关的分为一组，把“任务”相关的分为一组？这是个让人头疼的问题。也许你会说需要业务人员的输入，但是业务人员很可能只会告诉你这些概念之间都有关系。
2. 不健康的聚合上下文
   聚合分组法很容易导向一种按照聚合划分的架构。服务围绕聚合建设，而非针对某个业务价值，也就无法提供正确的业务价值。围绕聚合建设的服务，看上去可以复用，但是会造成服务间的紧耦合，容易成为最糟糕的分布式单体架构：
   当架构是分布式单体时，往往需要同时修改多个服务，同时部署多个服务、服务之间调用非常频繁。
   [You’re Not Actually Building Microservices]
   聚合分组法也无法很好的识别“重复的概念”问题（[领域驱动设计]14.1，指某一个概念，应该被设计成多个模型，因为它们有不同的规则，甚至有不同的数据）。使用聚合分组法往往导致把带着这样的聚合简单的放到某个限界上下文中。
3. 隐藏的划分方案
   还很可能是这种情况：在使用聚合分组法时，架构师已经有一个隐藏在心里的模糊的划分方案，在划分限界上下文时都是往该方案上靠。但是由于这个划分方案只是模糊存在于架构师的脑中，并没有拿出来讨论，很可能经不起推敲，最终无法言说，沦为“by experience”。

如何划分限界上下文

如何划分限界上下文？在回答这个问题前，让我们先看看限界上下文到底是什么。

在[领域驱动设计]第14章提出了著名的限界上下文。限界上下文是为了分解大型模型：

然而在几乎所