领域驱动设计的缺点？
我可能有一个关于 DDD 的愚蠢问题： DDD 通常有什么缺点吗？我的意思是，除了在没有必要或需要时使用它之外。 （例如小型/不复杂的项目）
谢谢
I might have a silly question about DDD:
Are there any disadvatages of DDD generraly? I mean, besides of using it when it is not necessary, or needed. (e.g. small/not complex projets)
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
很容易做错。
It is very easy to do it wrong.
Eric Evans 在 JavaOne 演示中表示，当业务领域存在大量复杂性时，DDD 最适用。此外，他明确指出 DDD 不适合解决技术复杂性很高但业务领域复杂性很小的问题。后者的一个例子是一个嵌入式系统，其输入非常简单（可能与其拥有的状态数量无关），同时呈现出大量的技术复杂性（在让硬件工作方面）。
我们如何量化很多或一点，这是一个开放的话题。但这种叙述应该作为 DDD 何时何地最适用的指南。
-- 编辑 --
我通过 Emule 获得了视频演示，但我从未在 YouTube 或类似视频场所找到相同的讲座。
Eric Evans has said in a JavaOne presentation that DDD is best applicable when there is a lot of business domain complexity. Moreover, he explicitly states that DDD is not suitable for problems where the is substantial technical complexity but that has little business domain complexity. An example of the later is an embedded system with very simple inputs (possibly independent of the number of states it possesses) while simultaneously presenting a lot of technical complexity (in terms of getting the hardware to work.)
How we go about quantifying a lot or a little, that's an open subject. But the narrative should work as a guideline of when and where DDD is best applicable.
-- edit --
I got the video presentation through Emule, and I've never been able to find that same lecture on youtube or similar video venues.
我在 Microsoft 应用程序架构指南中找到了关于 DDD 的讨论有助于理解该特定风格的挑战：
I found this discussion of DDD in the Microsoft Application Architecture Guide to be helpful in understanding the challenges of that particular style:
在一次意大利会议上，我谈到了这个主题（请参阅这些幻灯片）。
DDD 项目需要领域专家，但聘请这些专家的成本往往很高，因为他们拥有宝贵的知识（请阅读，如果您不需要领域专家，那么您就不需要 DDD）。
此外，DDD 需要建模者具备强大的技能。特别是，他们必须：
找到这样的开发人员可能比预期的要贵得多，因为经过几个月的尝试后你才能真正知道他们擅长这项工作。
At an italian conference, I talked about the topic (see these slides).
DDD projects require domain experts that are often expensive to hire, since they hold valuable knowledge (read, if you don't need a domain expert, you don't need DDD).
Moreover DDD requires strong skills on the modeler side. In particular they have to be:
Finding such developers can be much more expensive than expected, since you can really know that they are good at the job after some months of trials.
Martin Fowler 在他的“PoEA”书中对何时以及使用什么域逻辑模式进行了精彩的讨论。
例如，最简单的模式事务脚本不涉及域模型。
Martin Fowler in his "PoEA" book has a great discussion of when and what domain logic patterns to use.
For instance, simplest pattern, Transaction Script, involves no domain model.