我对DDD很新，想知道你可能想要分享的任何陷阱。我将在稍后总结一下，以便更多新手阅读：）
由于
到目前为止摘要：
此主题也有很好的演示here（视频）。
答案 0 :(得分：34)
可能是最重要的一个：不要理解领域模型的核心基本原则及其在泛在语言中的表现。有了大量的技术选择，你的头很容易填满ORM，MVC框架，ajax，sql vs nosql，......所以你要解决的实际问题还有很小的空间。
这是DDD的关键信息：不要。相反，首先要明确关注问题空间。构建一个破坏架构混乱的域模型，捕获，公开和传播域。
哦，另一个：认为您需要域服务来处理您在域模型中可以做的所有事情。不应该。您应该首先尝试将域逻辑与其所属的实体/值类型放在一起。只有在找到自然不属于E / V的功能时，才应创建域服务。否则，你最终会在其他地方突出显示贫血领域模型。
第h
答案 1 :(得分：14)
最大的缺陷之一是你最终得到了一个所谓的anemic model，你的实体主要只是数据承载而且不包含业务逻辑。当您在现有关系数据模型之上构建域模型并且只是使数据库中的每个表成为域模型中的实体时，通常会出现这种情况。
答案 2 :(得分：12)
答案 3 :(得分：7)
没有足够使用bounded contexts。这是蓝皮书的背后，但埃里克埃文斯已经记录在案，他说他相信有限的语境和无处不在的语言是最重要的概念。
同样，人们倾向于过分关注模式。那些不是DDD的肉。
此外，如果您没有很多访问域专家的权限，那么您可能不会使用DDD，最多只能使用DDDish。
更具体地说，如果你最终得到多对多的关系，你可能设计了一些错误的东西并需要重新评估你的聚合根/上下文
答案 4 :(得分：5)
只添加其他人已经说过的内容; 我个人的经验是，人们经常最终得到贫血模型和单一模型，而不是多个特定于上下文的模型。
另一个问题是，许多人更关注DDD中使用的基础设施和模式。 仅仅因为你有实体和存储库并且正在使用（n）Hibernate，这并不意味着你正在做DDD。
答案 5 :(得分：4)
这不是我个人对主题的体验，但它在DDD书籍中被提及了几次，这是我最近一直在考虑的事情：当你真正需要身份时使用实体，在其他情况下使用价值对象。即，实体模式经常恰好是任何模型名词的默认选择，并且它不应该是它应该的样式。
答案 6 :(得分：3)
小心 Big Ball of Mud 。
域驱动设计的一个缺陷是在模型中引入歧义。正如文章Strategic Domain Driven Design with Context Mapping中所解释的那样：
模棱两可是我们的超级恶棍 无所不在的语言
当两个不同的概念共享相同的名称，或者当相同的概念可以具有不同的用途时，可能会发生这种情况。可能有必要
公开域结构 上下文中有界上下文的术语 图
如果某个模型的使用方式太多，或者责任太多，则可能表明它应该被划分。