Big Blue 系列 — 11 — 建模时，只关注领域问题
Big Blue 系列 — 11 — 建模时，只关注领域问题
模型很像具有动态功能的面包食谱。当您建模时，希望您使用域来详细说明有界上下文以及成功的秘诀。
随着我们放慢对 Blue (Evans, 2004) 前三章的更多理解，我们现在可以开始思考如何更多地了解我们应该建模什么以及应该搁置什么。 Evans 在第一章中进行了大量研究，帮助将领域提炼为模型友好的设计。在我看来，这本书的精髓在于对领域建模的驱动力，专注于领域需求，仅此而已。
这是面包食谱从未有过的。它从来没有关于如何使用烤箱的说明，只是需要什么温度和持续时间以及任何其他特殊说明才能在烤箱中为这个食谱制作好面包。面包食谱也从来没有关于如何建造烤箱、订购、安装甚至更换烤箱的说明。面包食谱假设您有足够的烤箱空间，烤箱可以工作，可以达到温度并可以制作这种面包。在软件中，我们需要将支持架构的关注点与领域配方、领域模型分开。
无论您使用哪种架构，您都需要选择一种架构，或者发明一种（通常是一种利润较低的选择），它可以让模型成为配方，而无需关心或了解它所生活的世界其他地方。
这是重要知识的关键部分。我们的世界里有一片软件海洋。如果我们可以将业务独特的食谱与平凡或琐碎的食谱区分开来，那么我们已经做了一些事情来在需要升级食谱时分散注意力。分层、六边形和其他类似类型的架构允许您以这种方式构建域模型。
另一种说法是，当你向一位值得信赖的导师寻求建议时，你首先说“我有一个朋友需要对某事做出决定”，然后继续解释“朋友”的需求，导师可以提供急需的输入，不知道将如何实施或由谁来实施（所以我们认为 - 眨眼）。
您的域有大量的实施需求，但它们与构成成功秘诀的域策略和程序不同。是的，做出这种区分并遵守纪律是一项具有挑战性的工作——尽管如此，还是有回报的。它在许多层面上都是有益的，但我已经在本系列的前十部分中出售了这个想法。
当然，您可能需要在任何业务、客户、产品等中都能找到的常用标签食谱。但他们应该对其他公司具有独特的能力，并且在模型中，他们应该有权管理自己的需求。我们在我们的设计中实现了这一点，为他们提供了他们需要的东西来做出他们需要的选择来执行域策略并产生域结果。成分通常是各种类型的实体、值和事件。您选择的软件语言中的任何构造都是制作这些（接口、类、属性、方法，例如 OO 中的）的公平游戏，但根据领域成分的需要，某些构造更适合。这是领域驱动设计的一种方式。域的需要是最重要的。组装这些成分通常在具有服务的聚合中完成，并且在模块中，该聚合的元素之一充当“根”对象。
随着我们在本系列中继续进行，我们将深入了解所有这些成分类型以及如何形成它们，但我想在这里提出的主要观点是，域有需要转换为独立模型的配方。如前所述，领域专家拥有使这些食谱奏效的秘方。事实上，即使是领域专家，这些秘密也难以捉摸，因为他们做了他们需要做的工作，但并不真正知道如何以一种可以为软件自动化建模的方式表达配方。这就是领域专家和领域建模师（通常是 DDD 架构师）的协作真正派上用场的地方。
“但我有很多隐藏的食谱！”你可能在想。这可能是真的，也可能不是。以我的经验，四五个感知模型通常被简化为一对接受动态输入的模型，从而使模型更有用。但是，假设您有很多食谱。然后，您将需要专注于最重要的要建模的配方，并以多种方式设计它们。在 DDD 中，您希望简化这些领域想法的表达，过滤出实现，并查看您在不同模型变体下获得的权衡取舍。要做到这一点，您将需要退后一步并建模，一次又一次地建模，直到这种工作模型的感觉变得非常明显。
以这种方式建模需要一些练习、耐心和毅力。开发这是一门艺术，这是我个人从 Eric Evan 的再现课程中学到的。我强烈推荐 Eric 的 DDD 再现周，特别是对于阅读本系列、Blue 和其他书籍的架构师，但它很有价值，尤其是当团队一起学习这一切时。
直到那时…
我希望我能在下一部分见到你—— 大蓝系列 .
参考
埃文斯，E.（2004 年）。 领域驱动设计：解决软件核心的复杂性 .艾迪生-卫斯理专业
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
