领域驱动设计的缺点？

Question

关于DDD,我可能有一个愚蠢的问题:DDD是否存在任何不正常的问题？我的意思是,除了在没有必要或需要时使用它.(例如小/不复杂的项目)

谢谢

Answer 1

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

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

- 编辑 -

我通过Emule获得了视频演示,而且我从来没能在youtube或类似的视频场所找到同样的演讲.

Answer 2

做错很容易.

Answer 3

我在Microsoft应用程序架构指南中发现了对DDD的讨论,以帮助理解该特定样式的挑战:

由于该软件的核心是域模型,它是这种共享语言的直接投影,它允许团队通过分析周围的语言来快速找到软件中的空白.创建共同语言不仅仅是接受领域专家的信息并应用它的练习.很多时候, 开发团队中的沟通问题不仅是由于误解了域的语言,而且还因为域的语言本身是模糊的.域驱动设计过程不仅要实现所使用语言的目标,还要改进和优化域的语言.这反过来有利于正在构建的软件,因为该模型是域语言的直接投影.

为了帮助将模型维护为纯粹且有用的语言结构,您通常必须在域模型中实现大量隔离和封装.因此,基于域驱动设计的系统可能以相对高的成本出现.虽然域驱动设计提供了许多技术优势,例如可维护性,但它应该仅应用于复杂域,其中模型和语言过程在复杂信息的通信中提供明显的好处,并且在域的共同理解的制定中.

Answer 4

在意大利会议上,我谈到了这个主题(见这些幻灯片).

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

1. 谦虚,因为他们必须接受他们的无知并向专家学习
2. 非常熟练的OOP
3. 勤奋,因为他们必须跟踪决策
4. 通信,因为他们必须向其他开发人员解释域名(甚至通过文档)

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