是什么让我的代码DDD(域驱动设计)合格？

Question

我是DDD的新手,我正在考虑在我的项目中使用这种设计技术.

然而,DDD让我印象深刻的是这个想法有多么基本.与其他设计技术(如MVC和TDD)不同,它似乎不包含任何突破性的想法.

例如,我相信你们中的一些人会有同样的感觉,根聚合和存储库的想法并不新鲜,因为当你在编写MVC Web应用程序时,你必须有一个单独的主对象(即根聚合)包含模型层中的其他次要对象(即值对象和实体),以便将数据发送到强类型视图.

对我来说,DDD中唯一的新想法可能是

• "智能"实体(即您应该在根聚合上有业务规则)
• 值对象,根聚合和实体之间的分离.

谁能告诉我,我是否错过了这里的任何东西？如果这就是DDD,如果我用上述2个新想法更新我现有的MVC应用程序之一,我可以声称它是TDD,MVC和DDD应用吗？

Answer 1

简短的回答是,它不是你的代码看起来像是一个DDD项目,它是你如何达到该代码.现在为长版...

对于DDD编码实践没有任何革命性的东西,你是完全正确的,但你似乎对你的问题有点偏离目标.许多开发人员使用DDD的一个常见错误是过多地关注编码实践,而忽略了DDD的一些更基本的概念.DDD的核心是通过开发人员和领域专家之间的密切合作来迭代开发模型.您可以编写所需的所有服务,实体和值对象,但如果您没有在过程中涉及领域专家,或者没有通过迭代改进模型,那么坦率地说,您不是在练习DDD.即使从编码的角度来看,许多人也会考虑聚合根的概念,

你并不是唯一一个了解DDD的人.我发现几乎所有的开发人员都经历了一个DDD阶段,他们试图使用实体,价值对象和服务来实现样本应用程序,同时忽略所有其他对DDD至关重要的实践.DDD是一个旨在处理复杂业务逻辑的过程,因此判断一个周末开发的示例应用程序的优点并不能让您获得DDD所能提供的最佳功能.我敦促你继续深入研究DDD,因为我发现它是一个不可或缺的工具,但永远不要忘记它不仅仅是一种模式语言.

Answer 2

DDD并不是一个真正的清单 - 这是一种方法论.

除了Stefans的答案,我建议如下(按重要性顺序):

• 无所不在的语言 - 您的代码是否使用与业务相同的名称/术语？您的域对象使用与业务相同的名称吗？
• 行为 - 大多数行为/逻辑是否直接与域对象相关联,或者您是否有很多愚蠢的DTO？
• 有界背景 - 您是否明确界定了责任范围和关注点？
• 聚合 - 您是否根据根对象识别了聚合,以及强制执行业务不变量的锁定策略？
• 存储库 - 是通过存储库完成所有数据访问/查询,还是在其他类中有SQL代码？
• 域服务 - 您是否拥有不自然适合域对象的业务逻辑的域服务
• 规格 - 您是否在规范中包含了很好的业务规则？
• 查询规范 - 您是否在查询规范中包含了预先封装的查询/过滤器？

然后还有其他的东西!

我想大多数DDD从业者都想说:

" 我与领域专家合作,了解他们的需求,并编写(a)与企业条款和流程相匹配的系统,(b)帮助其他开发人员了解业务领域,以及(c)可以灵活地适应不断变化的业务需求. "

希望有所帮助!