<分区>
我刚刚写了一个很长(而且很乱)的blogpost关于我目前对领域驱动设计的看法，大量使用 spring 和 hibernate 等框架。
我会请您指出我对此事的看法是否存在任何问题 - 为什么这行不通，为什么它没有提供 DDD 的好处，为什么它通常不是一个好主意。
The blogpost is here (我认为我不需要将其复制粘贴到 SO - 如果您认为我应该，请告诉我)。
我知道这个问题是主观的，但它旨在收集最主流的意见。
(我在标记 Java，因为讨论的框架是 Java 框架)
最佳答案
我刚刚花了一年时间拆解一个应用程序，以消除贫血域反模式及其对 Hibernate 的误用。
我可以毫无疑问地说，DDD 产生的代码更容易理解和重构。在我们的例子中，删除了无数不必要的 getters 和 setters，增加了封装，集中了业务逻辑，以及伴随 DDD 而来的服务层的(显着)简化使得系统更容易维护现在我相信我们能够完成它，而在它被拖到永远之前。我们已将此应用程序的行数减少了 50%，但没有删除任何功能。
我还相信 ORM 工具的全部意义在于让我的业务逻辑与持久性代码保持一致。当我们有一个贫血领域模型时，我们为每个领域类都有一个 DAO，现在我们有一小部分 DAO 作为“主要”领域类上 CRUD 的入口点，但其他“次要”领域类由他们的 parent ...不是因为持久性逻辑在 parent 中，而是因为 Hibernate 透明地对业务逻辑使用react并使一切正常工作。
简而言之，我无法回答这个 SO 问题，因为我 100% 强烈同意您的帖子……并且每天都在生活中。
关于java - 您发现这种领域驱动设计的观点有什么问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2519517/
相关文章：
javascript - ES6 Method Definition Shorthand 是否只创建一个函数对象？
language-agnostic - 实体的 id 作为构造函数参数还是通过 setter 方法？
JavaFX 从 StageStyle.Utility 禁用最大化按钮
java - 单元测试在标记为 @Transactional 时通过，但在未标记为 @Transactional 时失败
domain-driven-design - CQRS - 如何处理新的报告表(或 : how to import ALL history from the event store)