Uml 对象模型在领域驱动设计中的重要性

我们的团队对领域驱动的设计相当陌生。我们有一个新项目，刚刚从设计阶段进入编码阶段。在设计阶段，一些团队成员在Visio中创建了UML设计模型，而其他团队成员则刚刚开始编码。此外，由于构建版本的压力，我们的许多模型很快就过时了

---

使对象模型保持最新是否重要？对于所有/大多数子系统，是否有必要使用它们

代码（和模型）的最佳文档是代码和数据库模式。在代码之外开发模型对于理解问题有一定的价值，但正如您最终发现的那样，这些都成了一种负担。如果你打算使用它们，你需要投入时间让它们保持最新。敏捷哲学会说，只要你从中获得了价值，就要在维护上投入同样多的时间。一般来说，这并不多，因为代码是最终的权威。如果您有法规要求，则可能是另一种情况，但我通常会在将模型转换为代码后丢弃该模型，如果您需要文档来描述它，我会根据需要直接从代码/模式重新生成该模型。

我猜答案是“视情况而定”，不是吗

如果项目很小，变化速度很快，等等，那么模型的ROI很可能很差，最终重要的是工作代码

另一方面，对于具有高度仪式性、不断变化的开发团队等的多年多阶段项目，您将从某种文档中获益匪浅。对象模型可以是这样的文档之一

---

毕竟，没有什么灵丹妙药，因此，根据项目规模的大小，您可能会发现模型非常有价值，或者只是维护成本很高。

任何类型的文档的目标都是帮助开发，而不是阻止开发。开发人员知道模型是怎样的，以及代码中的内容和文档中的内容之间的主要区别

但是，你应该意识到，你没有任何材料（除了代码本身）可以展示给团队中的新员工，而且要花一些时间来教新员工

---

因此，这是一个决定什么是最有效的问题。如果使模型过时会使团队更快，则不要更新模型。如果更新模型将在一定程度上改善开发，那么您应该这样做（无论多么无聊）

任何低于该级别的文档都与实现细节直接相关，因此与不稳定的事实（为什么与如何）直接相关。因此，It（如何、模型）不应手动维护，而应在需要时生成，以改善开发人员的沟通

文档在任何时候都可以维护，这很好。如果您不能保证这一点，那么可以使用源代码文档（并在更改代码时进行维护），在需要时从代码中生成尽可能多的UML

然后再次扔掉生成的文档。它只是为了帮助您更好地与开发人员沟通。它没有比这更大的价值了

---

今天刚拿到：一位开发人员拿着一张漂亮的Visio图表走近我，它打印在纸上，看起来非常漂亮。我打开IDE，向他展示源代码与他手中的文档略有不同。我花了一些时间来澄清代码胜过文档。始终。

您是否在问：“保持文档与代码同步（在执行DDD时）是否重要？”“是的，这是问题的一部分，而且如果模型在第一个位置上相对重要。在Visual Studio中，您可以将模型类拖到类图上，并使其自动更新。与保持UML图最新相比，VS仍然有助于在远离计算机的情况下进行设计审查。根据我的经验，VS在类建模方面的能力非常有限，但我听说2010年可能会在这方面有所改进。我不知道有哪种软件可以从对象自动生成智能、易于理解的UML模型……这真的可能吗？