蓝色巨人系列 — 08 — 情境作为一种策略
蓝色巨人系列 — 08 — 情境作为一种策略
如果你一直在关注这些文章 大蓝系列 ，你会看到领域驱动设计 (DDD) 非常强调学习现实世界的深度，这比我们通常不尝试建立模型时的学习程度更高。
当我研究这个主题以完善我的理解并努力使其清晰时，我经常发现其他出色的解决方案提供商正在做 DDD，解释它，然后告诉他们的听众跳过这本书我称之为“蓝色”（Evans，2004）和直接看实施书。我明白了诱惑。他们本质上是开发人员。他们希望倾听他们的开发人员继续受到鼓励。
也就是说，我对跳过模型制作理论的想法感到畏缩，因为这种技能是我们更好地知道要编码什么的方式。如何编码更容易学习。书籍、视频、教程等可以让任何人快速了解如何在他们的解决方案中创建最佳的新软件模式。要编码什么？现在这是真正难以培养的技能。
今天，我们着眼于从高层建模领域来构建解决方案，Blue 在第 14 章中将其描述为有界上下文。这个话题是火线。我会尽力不被击中，同时我会尽量不要玩得太安全。我想描述足够多的内容，以便您可以开始以一种更容易查看您的解决方案是否符合域需求的方式来思考您的应用程序。
它经常被争论。什么是域？什么是限界上下文？他们是一样的吗？如果没有，是否有等级制度？问题层出不穷。这是 Blue 中最困难的概念之一。我花了很多年才开始理解，我仍然会学习，我只是想慢慢地学习更深。无论如何，我现在想解决它，以便我们为所有其他概念（如聚合、实体、存储库等）提供一个框架。
正如 Blue 在第 2 页所描述的，领域是现实生活中的主题领域。
有界上下文，正如 Blue 在第 336 页所描述的那样，围绕域模型设置边界。
你明白了吗？
域是真实的。现实世界。
限界上下文是我们为理解现实世界而制作的现实世界的派生。
有界上下文可以与多个域相关吗？是的。适合你吗？也许不吧。要看。这不那么令人担忧，因为随着您建模的次数越来越多，这一切都会变得明显。到目前为止，我已经了解所有这一切，领域实际上是问题空间的非技术视图，而有界上下文是一组有边界的商定模型，代表他们所服务的一个或多个领域。
您可以从字面上选择按企业中的部门划分域，然后选择使每个部门都成为有界上下文。这将是一个幼稚的高级模型结构，可能 80% 的时间都有效。但是你想要一个更好的数字。
一个例子值得在这里描述。
我要你记住，这不是一个公式。您是该领域的思考者，也是您将要构建的上下文的建模者。这只是一个想法，而不是实现的模式。
精油等
我曾经在一家蒸馏、储存、混合、装瓶和运输精油的公司工作。
最高级别的领域是精油行业。公司的每个主要职能都是一个子域。如果这是在特定情况下讨论的最高级别，则可以将术语域应用于每个子域。
在仓库中，您会发现几个过程正在发生。如果符合 CEO 的质量要求，来自相同植物材料的原料油将被储存。如果要将它们作为单一油装瓶，则在该存储位置附近进行另一个装瓶过程。如果要制作混合物，则需要根据特定配方混合油的功能。一旦这些混合物制成，它们就被储存在靠近原料油的地方，最终也装瓶。
每个小组都需要使用精油，但除此之外，他们几乎没有其他共同点。每个小组都有自己独特的流程，但他们必须一起处理有关他们所使用的精油的数据。
混合油的小组是一个很好的例子，说明了为什么您可能拥有一个可能涉及多个有界上下文的域/子域。一方面，它有一个混合上下文，有助于定义什么是配方以及如何从这些配方中创建混合物。另一方面，它需要从仓库系统访问原料油背景和存储详细信息，以确保有足够的正确油来生产混合物。一旦创建了混合物，混合组将需要提供该混合物的批号和其他详细信息，以便可以将其发送到等待装瓶的存储处。该领域实际上是混合上下文的候选者！
为代表所有这些的模型绘制有界上下文边界的位置在这里并不固定。永远不应该。我们需要从不同角度查看领域并开发其替代概念模型的能力，其中最高级别是有界上下文。
域是现实世界中关注的领域。有界上下文是我们制造的高级模型，可以开始为这些领域提供解决方案集。我们有这种灵活性是可以的，事实上它是首选。
下一篇文章是关于为什么我们需要一个上下文——无所不在的语言。我最喜欢的话题之一！
直到那时…
我希望我能在下一部分——蓝色巨人系列中见到你。
参考
埃文斯，E.（2004 年）。 领域驱动设计：解决软件核心的复杂性 .艾迪生-卫斯理专业
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
