Get best of the week

使用边界上下文画布设计边界上下文：研讨会食谱

即将举行的TechLead Conf 2020会议的主题包括对域驱动设计和EventStorming的详细讨论。除了准备康斯坦丁· 古斯托夫（Konstantin Gustov）关于DDD的2槽报告，谢尔盖·巴拉诺夫（Sergey Baranov）关于EventStorming的报告，以及将在其中创建DDD雷达的mitap之外，我们还决定翻译一篇有关设计边界上下文的最流行方法之一的文章。

如何将大型系统分解为更小，更易管理的组件？经常有人问我这个问题，因此我在本文中收集了我的知识。

在DDD中，大型系统被分解为有限的上下文 （翻译者的评论：以下将它们称为有限上下文），这些上下文已成为自然的边界，例如代码中的微服务和组织中的团队。

无法快速轻松地确定有界上下文的良好边界。这需要对业务和主题领域有广泛而深入的了解。该研讨会格式旨在满足这两种需求，并使用两种工具来查找最有效的系统设计：EventStorming和Bounded Context Canvas。

图片

“在公开活动和公司会议上举办DDD研讨会的过程中，我开发了此画布。如果找到最适合您的格式，请随时更改其结构。”

食谱


主要配方包括以下内容：

  1. EventStorming（至少1小时）。
  2. 为有限制的上下文（最少30分钟）建模候选人。
  3. 模拟域消息流（至少30分钟）。
  4. 边界上下文画布（至少90分钟）。
  5. 创建上下文地图（至少45分钟）。

首先，我建议为该研讨会分配一整天的时间。这将帮助您了解正确进行研讨会的真正时间。如果将所有人聚集在一起很昂贵（很耗时），请尝试立即分配两天时间以完成所有工作。

理想情况下，参与者应该是主题专家和技术专家。如果这很难组织，请尝试确保领域专家至少在第一个小时在研讨会上。

建模的基本原理


要与专家进行会议，您需要一个宽敞的房间。如果您选择的受众较少，那么您很可能会对结果感到失望。每4人一组的墙壁上至少需要4米。

我将以自由形式描述我的方法，没有严格的规定。但是，请记住：
“我们一直在问题空间和解决方案空间之间切换。“我们正在寻找信息，创建模型，寻找其他信息，更新模型等。”
还有一个重要的观点：本次会议的目的是开发选择方案，并提高将来提供更好选择的能力。

1.事件存储


要设计一个系统，您需要做两件事：对整个系统有足够好的一般概念以及对每个领域的细节都有相当深刻的理解。为此，让我们从EventStorming开始。

EventStorming是一种协作设计方法，它使您可以从头到尾模拟大问题区域，还可以在必要时深入挖掘大量细节。

图片

如果这是您第一次这样做，建议您在EventStorming上预留1-2小时。完成EventStorming后，我建议分成4人一组。
在2020年TechLead大会上，Sergey Baranov将谈论EventStorming的实践经验。

2.寻找候选人的有限背景


在根据EventStorming对域进行广泛而深入的建模之后，您可以开始在有限的上下文中对片段进行分组和合并。

图片

有许多确定有界上下文的方法。我建议从以下内容开始：

  • 从价值开始-确定领域中对业务最有价值的核心部分。
  • 从一个简单的例子开始 -通过将时间线分成连续的步骤来创建一个简单模型。
  • 查找关键事件-影响业务流程不同部分的业务事件。

第一次，在此任务上花费不超过30分钟。邀请小组以创建原始有界上下文模型为起点。它不一定是完美的，也不可能是最终的解决方案。

输出应在活动挂图或纸上的有界上下文名称列表中。如果您有多个组，则无法实际修改EventStorming。

下一步


您可能会立即看到几种对系统建模的方法。现在，选择其中一个进行工作并写下其他可能的模型（稍后将用到）。您还可以了解您缺少域信息。如果是这样，请执行另一轮EventStorming。

3.建模域消息流


验证设计并寻找改进点的一种方法是可视化完整业务系统场景中有限上下文的交互。

如果事实证明域流很复杂，具有大量依赖关系和双向连接，则您的设计很脆弱，需要进一步分析。

有许多可视化方法可用于对流程和用例进行建模，包括UML序列图和UML用例图。我建议使用域叙事选项。

在对主题域的消息流进行建模时，有限的上下文是故事中的参与者。因此，一个典型的故事始于用户试图实现某个目标，并且有界上下文之间的交互旨在为用户提供解决方案。

图片
域消息流的虚构示例对

战略性域流进行建模可让您获得有关建议的有界上下文的反馈。它显示了上下文如何相互协作以及如何相互依赖以完成完整的业务流程。这可以帮助找到替代设计。

您应该问自己的问题是，每个有界上下文的描述是否与它在域流中扮演的角色相匹配。如果不是这样，则可能需要重新设计名称或上下文边界。

下一步


由于您的领域流程决定了有限上下文之间的关系，因此您可以立即发现明显的设计缺陷。您可以返回到上一个操作，并为有界上下文更新候选者，或者执行EventStorming的第二次迭代。您也可以写下您对设计的想法，并在开始重新设计之前收集有关下一步的更多信息。

4.边界上下文画布


设计的下一阶段是使用关键设计标准的详细信息，为有限的上下文开发候选对象。您的团队应该选择您认为最重要的有限上下文。讨论最多不得超过3分钟。100％准确并不重要。

现在，绘制“边界上下文画布”，并按照以下步骤填写细节。我建议使用1张大小相同的活动挂图或纸。
完成这些步骤之后，重复该过程，直到您确定了所有有界上下文。尝试将您的时间平均分配给有限范围内的候选者。

4.1一般情况的定义


首先定义边界上下文的名称及其描述。描述应显示域中上下文的目的及其在业务中的作用，而不是实现细节。

接下来，您需要进行战略分类。有界上下文是系统的主要部分，辅助元素，公共元素还是其他东西？如果您需要选择帮助，请阅读Vlad的帖子。

图片
例如，经过第一步后，填充的有界上下文画布。

下一步


如果您不能给出一个清晰的名称，或者不能写一个连贯，准确的描述，或者您对通用语言（UL）的用词不明确，请考虑将其作为您设计的反馈。考虑重新设计边框，或记下便笺，然后再回来（通常最好再回来）。

4.2澄清业务规则并形成通用语言


现在回到EventStorming并查看有关此受限上下文的注释。找到最重要的业务规则和策略，然后尝试选择最重要的3个规则并将其添加到画布中。
康斯坦丁·古斯托夫（Konstantin Gustov）在2020年TechLead大会上将谈到他在Raiffeisen的无处不在语言和其他DDD组件方面的多年工作经验。
这也是搜索关键业务词或短语并将其添加到“泛在语言”部分中的画布的好时机。您将在整个研讨会中继续添加单词和短语，现在这仅仅是一个起点。

图片

4.3特征分析


下一步是探索有限上下文提供的可能性。这不仅澄清了他在做什么，而且还为设计提供了很多反馈。您可以提出以下问题：

  • 这种情况是否充满了责任？
  • 机会看起来相关吗？
  • 功能是否与上下文的名称和描述匹配？
  • 如果我们将此机会移出上下文怎么办？

通过引入公共界面开始定义机会。消费者可以从此受限上下文中请求什么，他们可以调用哪些命令？使用域数据流从此受限上下文中查看消费者需要什么。

并非所有功能都由外部命令和请求激活。某些功能可能是从内部启动的。例如，计划任务。有时您可能会注意到机会是集群的，例如，命令，请求和通知。如果是这样，请将它们放到画布上，并为群集命名。

您可能会感到责任不适当，应该与另一个有限的上下文有关。如果是这样，请在标签上带有某种识别标记的方式进行选择。

图片

下一步


如果发现难以确定上下文功能或感觉其中某些功能缺失，建议您返回EventStorming并对该边界上下文进行更详细的建模，重点是查找其他上下文或服务所需的功能。

加深功能[可选]


在画布上布置每一个机会，以获取更多功能。此附加详细信息将帮助您找到替代模型。如果画布上没有足够的空间用于放置零件，请在墙上找到另一张纸或空间。您可以根据需要选择更深的层。

4.4依赖关系


如果我们需要模块化，则依赖关系是必需的，但是依赖关系也会引起广泛的业务，技术和社会问题。因此，重要的是要查看依赖项，了解它们的影响，并考虑其他选择。因此，设计有界上下文的最后一步是确保您捕获有界上下文的所有关键依赖项。

查看EventStorming结果和域流程图，确定具有受限上下文的每个依赖项，并写下以下信息：

  • 另一个有界上下文或服务的名称；
  • 为何会上瘾的简要说明
  • 依赖关系在哪里：在此系统内部还是在外部系统（例如，第三方服务）中；
  • 关系类型：这是传入的依赖项（另一个服务取决于此受限上下文），传出的依赖项（此受限上下文依赖于另一个上下文），双向或用户界面（依赖项是某种类型的用户界面）。

询问每个依赖项：是否需要它，可用性的成本和收益是什么？如果似乎可以做到这一点，请用黄色标签标记依赖性。

图片

4.5建设性批评


完成画布的填充后，请花几分钟来严格评估边界上下文的最终设计。将您的评论分为以下几类：

  • 良好：您喜欢的设计方面。
  • 不好：您不喜欢的设计方面。
  • 不确定：您不确定的设计方面。

4.6。反思与重复


好的设计是迭代的。在转到下一个有界上下文之前，请退后一步并查看大图。您是否学到了与您的设计相反的东西？如果是这样，请划出建议的边界，然后继续设计下一个有界上下文。

此时，请问问自己是否对域进行了足够详细的建模。填充画布的某些部分难吗？如果是这样，请尝试在整个域或其中的某些部分进行另一轮EventStorming。

5.创建上下文映射


在为每个有界上下文创建画布并收集设计反馈之后，本节的下一部分将回到探索。这次您将拥有一整套知识，可以帮助您找到最佳的设计方案。

此练习的结果是基本上下文映射的集合-可视化有限上下文与您认为必要的任何其他图（例如域流图）之间的结构关系。每个团队必须至少开发3个上下文图，每个上下文图都将显示构建系统的可能选项。

图片
一个非常准确的上下文地图的示例，对于本次研讨会而言就足够了。

我们将在2020 TechLead Conf上举行一次mitap大会，在那里我们将分析DDD的各种技术，模式和反模式，并收集一个视觉雷达。该文件将在会议后发布。
最终活动可以自由形式进行。目的是审查收集到的信息，并使用它来开发许多系统设计。首先，我建议：

  • 查看针对每种情况收集的所有评论，并尝试“不好”和“不安全”的评论。
  • 问“如果”的问题...
  • “如果我们将这个机会转移到另一个有限的环境中怎么办？”
  • “如果我们抓住这个机会，将其中一个子功能移至另一个有限的环境，该怎么办？”
  • “如果我们将有界上下文分成几个上下文怎么办？”
  • “如果我们从这三个环境中的每一个中抓住机会，并在新的环境中使用它，该怎么办？”
  • “如果我们复制功能来消除成瘾怎么办？”
  • “如果我们创建通用服务以减少在不同情况下的重复，该怎么办？”
  • “如果我们将真正的关键机遇隔离开来，并在其他情况下将其余机遇转移到一个更加和平的地方，该怎么办？”

如果您希望可视化这些转换，则以下插图可能会有所帮助：

图片

图片

图片

研讨会闭幕


为了完成会议，每个小组应该展示他们创建的上下文映射的选择，并讨论每个设计的权衡。您需要解释您的选择，为此通常只需演示5-10分钟即可。

您需要在演示中考虑的内容：

  • : .
  • : .
  • , , .

- TechLead Conf 8 9 . 32 , , , , DDD .

- — ( , ). , .

More articles:


All Articles