大蓝系列 — 06 — 模型作为真相中介
大蓝系列 — 06 — 模型作为真相中介
如果您的团队设置为协作，并且您感到孤独，那么有些事情发生了。走开。内向或外向，孤独是有影响力和令人沮丧的。我曾在 2000 年和 2011 年担任过一个项目的唯一开发人员。我并不感到孤单，因为我解决了这个问题。我呼吁说真话的人帮助我了解什么是真实的，什么与该项目无关。
如果您来自制造背景，或者将软件视为一条装配线，可以通过削减所有看起来不像程序员编程的东西来提高效率，那么您将在这个行业中挣扎。我可以列出一些挣扎，但我不想陷入那个兔子洞。
软件更像是一个漏斗和过滤器。想法和概念化是否得到验证。好的想法会变成好的和坏的模型。好的模型变成了代码。学习漏斗和过滤是 DDD 的全部内容。域有很多很棒的想法。它也有其他想法。开发人员需要与领域专家一起学习如何将这些想法转化为模型。一旦对这些想法的相当好的表示进行建模，我们就可以编写测试，然后构建代码以使这些测试通过。这比在好的想法奏效之前将其砍掉更有效。
在软件设计方面，白板比键盘更有利可图。
我之前关于我称之为 Blue 的书（Evans，2004 年）的文章让我们了解一开始的罗马数字页面，让我们了解如何处理这种范式。然后在我的上一篇文章中，我们谈到了第 1 页和第 2 页。现在我们从第 3 页和第 4 页开始学习如何通过建模来进行协作并使其变得强大。这两页为我们提供了思考前三章的框架。这一切都是关于汇集和过滤在一起，并制作一个真正经得起时间考验的模型。并不是说模型不会改变，而是随着知识的获得和应用，它能够更快地改变。
概述的三个主要概念如下：
- 用模型写代码的时候，看模型就可以理解代码。
- 该模型为解决方案的该部分存储域的详细信息，其中包括域的实际措辞。
- 该模型是为相关概念过滤域的结果。
在这一点上，如果您了解流程图或 UML 或其他文档样式，那么您可能正在摸索您的敏捷头脑。是的。需要使用纸上的东西或数字白板或其他东西进行交流。我们需要以某种方式理解和处理设计。在功能的开始阶段，为了找到一个开始编写代码的好地方，我们需要就我们认为最能代表此解决方案中域需求的模型达成一致。将来如何选择使用该模型是您自己的选择，但我建议将模型与实现联系起来，以便它们一起工作以应对未来的变化。
有很多方法可以将领域知识汇集和过滤到领域智能模型中，从 阿尔贝托·布兰多里尼 的事件风暴，到餐巾纸，到服务蓝图，到示例映射。无论您选择如何建模，您都希望确保最终用户和工程人员都得到充分代表。随着人群变大，可能存在收益递减规律，但我很少看到这条规律被打破。
最后一点，代码需要是实现的模型。为了让整个事情发挥作用，我们在模型中使用的词、动作、状态、策略，所有的东西，都需要在代码中。如果模型不是代码，就没有理由建模。这是领域驱动设计，也就是领域驱动开发。
本系列的其余文章将重点介绍 Blue 的关键解决方案规划和开发概念，例如：
- 名字里有什么？
- 是什么？
- 何时将域的位组合在一起。
- 何时分开位。
- 如何翻转设计只是为了看看是否有更好的方法。
和更多。
直到那时…
我希望我能在下一部分——蓝色巨人系列中见到你。
参考
埃文斯，E.（2004 年）。 领域驱动设计：解决软件核心的复杂性 .艾迪生-卫斯理专业
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
