域驱动设计(DDD)陷阱

Question

我对DDD很新,想知道你可能想要分享的任何陷阱.我将在稍后总结一下,让更多的新手阅读:)

谢谢

截至目前的摘要:

• 贫困域模型,其中您的实体主要仅承载数据且不包含业务逻辑
• 不充分使用有界上下文
• 过分关注模式

有关于这个主题一个很好的展示,以及在这里(视频).

Answer 1

可能是最重要的一个:不要理解领域模型的核心基本原则及其在泛在语言中的表现.有了大量的技术选择,你的头很容易填满ORM,MVC框架,ajax,sql vs nosql,......所以你要解决的实际问题还有很小的空间.

那是DDD的关键信息:不要.相反,首先要明确关注问题空间.构建一个破坏架构混乱的域模型,捕获,公开和传播域.

哦,另一个:认为你需要域服务,你可以在域模型中做的一切.不应该.您应该首先尝试将域逻辑与其所属的实体/值类型放在一起.只有在找到自然不属于E/V的功能时,才应创建域服务.否则,你最终会在其他地方突出显示贫血领域模型.

心连心.

Answer 2

最大的缺陷之一是你最终得到了一个所谓的贫血模型,你的实体主要只是数据承载而且不包含业务逻辑.当您在现有关系数据模型之上构建域模型并且只是使数据库中的每个表成为域模型中的实体时,通常会出现这种情况.

Answer 3

你可能会喜欢演讲,为什么DDD失败Greg Young的的.

简而言之:

• 缺乏意图
• 贫困领域模型
• DDD-精简版
• 缺乏隔离
• 无处不在？
• 缺乏细化
• 代理域专家(业务分析师)

Answer 4

不充分使用有界上下文.它是在蓝皮书的背面,但埃里克埃文斯已经记录在案,他说他认为有限的背景和无处不在的语言是最重要的概念.

同样,人们往往过分关注模式.那些不是DDD的肉.

此外,如果您没有很多访问域专家的权限,那么您可能不会使用DDD,最​​多只能使用DDDish.

更具体地说,如果你最终得到多对多的关系,你可能设计了一些错误的东西,需要重新评估你的聚合根/上下文

Answer 5

只添加其他人已经说过的内容; 我个人的经验是,人们经常最终得到贫血模型和单一模型,而不是多个特定于上下文的模型.

另一个问题是许多人更关注DDD中使用的基础设施和模式.仅仅因为你有实体和存储库并且正在使用(n)Hibernate,这并不意味着你正在做DDD.