域驱动设计（DDD）的陷阱 [英] Domain-driven-design (DDD) pitfalls
问题描述
我对DDD相当陌生，想知道您可能想分享的任何陷阱。稍后我将对其进行总结，以供更多的新手阅读：）
I am quite new with DDD and would like to know about any pitfalls you might want to share. I will summarize it later for more newbies to read :)
谢谢
到目前为止的总结：
- 贫血域模型您的实体主要仅是数据承载的并且不包含业务逻辑
- 没有使用足够的受限上下文
- 在模式上过多关注
- Anemic domain model where your entities are primarily only data bearing and contain no business logic
- Not using bounded contexts enough
- Focusing too much on patterns
There is a good presentation on this topic as well here (video).
推荐答案
可能是最重要的一个：不要忽略域名的中心基本原理模型及其在通用语言中的表示。有了众多的技术选择，您很容易就可以将ORM，MVC框架，ajax，sql与nosql结合起来……...如此之多，几乎没有空间解决您要解决的实际问题。
Probably the most important one: not grokking the central, fundamental principle of the Domain Model and its representation in Ubiquitous Language. With the plethora of technology options around, it's very easy for your head to fill up with ORMs, MVC frameworks, ajax, sql vs nosql, ... So much so there's little space left for the actual problem you're trying to solve.
这就是DDD的关键信息：不要。相反，首先要明确地关注问题空间。建立一个结构混乱的领域模型，可以捕获，公开和交流领域。
And that's DDD's key message: don't. Instead, explicitly focus on the problem space first and foremost. Build a domain model shorn of architectural clutter that captures, exposes and communicates the domain.
哦，还有一个：认为您需要域服务才能完成域模型中的所有工作。不能。您应该始终首先尝试将域逻辑及其所属的实体/值类型一起放入。仅当您发现自然不属于E / V的功能时，才应创建域服务。否则，您最终将在其他地方突出显示贫血领域模型。
Oh, and another one: thinking you need Domain Services for everything you can do in the domain model. No. You should always first try to put domain logic with the Entity/Value type it belongs to. You should only create domain services when you find functions that don't naturally belong with an E/V. Otherwise you end up with the anaemic domain model highlighted elsewhere.
hth。
这篇关于域驱动设计（DDD）的陷阱的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
