领域驱动设计的缺点？

Question

我可能对DDD有一个愚蠢的问题： 是否有任何DDD的缺点？我的意思是，除了在没有必要或需要时使用它。 （例如小/不复杂的项目）

由于

Answer 1

Eric Evans在JavaOne演示文稿中表示，当业务领域复杂性很多时，DDD最适用。此外，他明确指出DDD不适用于具有 业务领域复杂性的大量技术复杂性但的问题。后者的一个例子是一个嵌入式系统，输入非常简单（可能与它拥有的状态数无关），同时呈现出很多技术复杂性（在使硬件工作方面。）

我们如何量化很多或一点，这是一个开放的主题。但是叙述应该作为DDD最适用的时间和地点的指导原则。

- 编辑 -

我通过Emule获得了视频演示，但我从来没有在youtube或类似的视频场所找到同样的演讲。

Answer 2

这样做很容易。

Answer 3

我在Microsoft Application Architecture Guide中发现了对DDD的讨论，以帮助理解该特定风格的挑战：

  

作为软件的核心是   域模型，这是一个直接的   投射这种共享语言，它   允许团队快速找到差距   在软件中通过分析   周围的语言。创造一个   共同语言不仅仅是一种语言   接受来自的信息   领域专家并应用它。   通常，沟通问题   在开发团队内部不应该   只是误解了语言   域名，也是由于   事实上，域名的语言是   本身含糊不清。领域驱动   设计过程不仅是目标   实现语言的   用过，但也改进和提炼   域名的语言。这个   转而使软件受益   建造，因为模型是直接的   领域语言的投射。

     

为了帮助维护模型   一个纯粹而有用的语言结构，   你通常必须实现一个伟大的   处理隔离和封装   在域模型中。所以，   基于域驱动设计的系统   可以来自相对较高的成本。   而Domain Driven Design提供   许多技术优势，例如   可维护性，应该应用   只有复杂的领域   模型和语言过程   提供明确的好处   复杂信息的传播，   并且在共同的表述中   了解域名。

Answer 4

在意大利会议上，我谈到了这个话题（见these slides）。

DDD项目需要领导专家，因为他们拥有宝贵的知识（阅读，如果您不需要领域专家，则不需要DDD）。 此外，DDD需要建模方面的强大技能。特别是他们必须：

1. 谦虚，因为他们必须接受他们的无知并向专家学习
2. 非常熟练的OOP
3. 勤奋，因为他们必须跟踪决定
4. Comunicative，因为他们必须向其他开发者解释域名（甚至通过文档）

找到这样的开发人员可能比预期的要贵得多，因为经过几个月的试验，你真的可以知道他们擅长这份工作。

Answer 5

Martin Fowler在他的“PoEA”一书中讨论了何时以及domain logic patterns使用的内容。

例如，最简单的模式Transaction Script不涉及域模型。