JPA和领域驱动的设计

JPA和领域驱动的设计不能很好地结合在一起。事实上，JPA“实体”是Fowler警告所反对的贫血数据模型的代表。我已经讨论过因此，我不会在这里详细介绍贫血数据模型是否不好(请记住：我不认为它是坏的)。

但是，对于需要将依赖项注入实体的时间，标准不会帮助您。唯一的选择是@Configable，这需要AspectJ编织，这对我来说是“黑魔法”。那么，为什么不能将依赖项注入实体呢？因为它们是由您创建的，而不是由依赖注入框架创建的。

好吧，有个奇怪的主意。如果JPA 3有EntityManager.createEntity(Foo.class)让你的实体一直被管理？然后，您将能够注入与其他实体不同的依赖项(JPA已经通过关联处理)。它将如何工作？

• JPA将需要一个DependencyManagerCdi当然是默认的依赖关系管理器，但是任何框架(Spring、guice等)都可以插入它们的实现。
• 无论何时创建(.)您的实体将有它的依赖项集--就像该实体是由您的DI框架创建的一样。
• 这意味着实体的“瞬态”状态将不存在(如果选择create()方法，即)

但…分离的实体，或者需要创建不应该访问实体管理器(例如控制器中)的实体的情况，是最重要的事情。我不能给你一个满意的建议。您要么需要注入EntityCreator，后者将使用实体管理器，要么使用另一个机制(如果您可能从JPA切换到其他机制)。但是这可能是一个“最佳实践”，而不是一个标准的接口，因为如果它是一个JPA接口，它仍然是Web层对JPA的直接依赖。另一种选择是通过所有层传播创建，但这是样板。第三种选择是，当分离的实体“进入”服务层时(通过AOP)自动附加。这个想法的一个缺点是人们会被诱惑注入Enti