支持 DDD 的企业应用框架

Posted 2023-02-21

【中文标题】支持 DDD 的企业应用框架

【英文标题】：Enterprise application framework supporting DDD

【发布时间】：2013-04-02 06:41:26

【问题描述】：

我花了很短的时间研究Habanero，我发现它是在很短的时间内制作企业应用程序的好方法。 正如开发人员所说，Habanero 使用的模式是“Active Record”。 我的问题是：

有任何类似的应用程序，如 Habanero 女巫完全支持域 通过确定聚合根、实体和值对象来驱动设计 在大型组织中使用此类工具是否正确的决定 是否值得在这样的工具上培训我们的团队

谢谢

【参考方案1】：

对领域驱动设计的框架支持与支持数据驱动应用程序的框架完全不同。这样的框架应该可以提高开发人员的工作效率，这些开发人员使用一种随业务发展的无处不在的语言，并且由领域专家学习。

他们不应该面对聚合、根、值对象等概念，因为它们只是建模概念、概念工具，而是简化开发过程的方法。因此，暴露名为AggregateRoot、Entity 或ValueObject 的抽象类或接口的框架从根本上被破坏了。它没有为应用程序提供任何真正的价值，只是无用的间接。

但是：

有一些框架旨在支持域驱动设计，listed here。此外，我正在根据之前运行良好的经验开发one by myself 显然，这取决于。例如，我们成功使用了 Epic 的所有建模模式。 我们也使用了一些“自制”框架，其中一些被证明确实提高了生产力。但是，此类框架（如果有用的话）总是有陡峭的学习曲线，这在很大程度上取决于软件必须达到多少reliable 以及开发人员的技能。 这取决于框架、业务的复杂性（如果您不需要领域专家来理解它，则不需要 DDD）以及开发人员。我在不同的背景下使用不同的框架面临成功的故事和巨大的失败。我还召开了一个针对该主题的会议（您可以查看幻灯片here）。

【讨论】：

“因此，暴露名为 AggregateRoot、Entity 或 ValueObject 的抽象类或接口的框架从根本上被破坏了。它没有为应用程序提供任何真正的价值，只是无用的间接”——我不同意对此，我成功地使用类似的框架 (CoreDdd) 对几个项目的域进行建模。我认为能够从 Entity 继承或将实体标记为 IAggregateRoot，我的 2c 有很大帮助

@xhafan 我认为使用 DDD 发送电子邮件没有多大价值。一个好的对象模型不是领域模型。如果您不需要领域专家来了解业务，则不需要 DDD。如果您必须了解一位或多位领域专家，那么处理聚合根是您的最后一个问题。您将必须深入学习他的语言和业务，并且必须为其他人必须能够快速理解的复杂、有据可查的代码库建模。如果您知道聚合根是什么，您就会知道接口不能强制执行不变量。这是不必要的。

开发人员应该能够从代码本身或其单元测试中理解代码，而不是从总是过时的“编写良好的文档”中理解代码。我相信不应该有代码文档。如果从代码或其测试中不清楚，请重构它以使其清晰。这就是为什么看到某个东西是聚合根（实现 IAggregateRoot）或实体（继承自 Entity 基类）会立即有助于理解代码。

@xhafan 在大多数面向对象的项目中，你是对的。在那些需要 DDD 的 5% 中，相信我：文档与代码一样重要。有时甚至更多。特别是在 C# 中，我们错过了已检查的异常，这一点很重要，客户知道调用可能出错的唯一方法是阅读最新的文档。如果业务规则足够复杂，需要聘请领域专家，并且您有超过 10 人需要快速掌握它才能完成工作，那么代码文档（和愿景声明）确实是必须的。

请注意，这并不意味着代码本身不可读（相反，我的领域模型通常形成内部 DSL），只是必须解释无处不在的语言，因为你可以在不同的有界上下文中找到具有略微（或完全）不同含义和规则的相同概念。