使用Spring的领域驱动编程

我有一个关于DDD和Spring的问题。我总是围绕着贫乏的领域模型和服务设计我的应用程序，考虑业务逻辑/持久性

假设您为域对象（例如Book）提供了spring管理的持久性/响应服务。如果我必须在book上公开save（）方法，那么我需要在域中使用存储库bean，或者我必须查找存储库bean的上下文。这与依赖注入正好相反

现在，如果我将存储库id注入域，并且域对象被缓存（集群缓存），然后在反序列化时，它将不会有注入的存储库服务，因为spring容器将不同

我可能是错的，但是如果有人能解释这个场景是如何工作的，这将是非常有帮助的

我认为“保存”方法（例如保存在数据库中）不属于域对象。。。这本书“保存”了自己吗？或者存储库正在保存它？…

我认为应用程序的“facade”应该使用存储库（或其他基础设施服务）来保存“book”。书籍不应自行保存，这是存储库的责任

如果您需要从域实体执行任何基础结构操作（例如，搜索数据库），那么您应该通过查找上下文（并因此耦合到Spring）或通过实体中的依赖项注入来注入存储库，从而获得对该存储库的访问权

问题在于实体的“实例化”不是Spring的责任，而是持久性提供者的责任，因此Spring无法处理这种注入。怎么办

好吧，有几种方法可以做到这一点（没有一种非常“漂亮”）：

• 通过AOP：您可以使用面向方面的框架（如AspectJ）来插入代码，配置系统，以便在实例化时在实体中注入任何依赖项
• 通过Hibernate拦截器：如果您的持久性提供程序是Hibernate，它将为您提供一个钩子，用于将拦截器放置在实体生命周期的某些点上。您可以配置一个查找spring上下文的拦截器，以便在每个实体的实例化中注入依赖项
• 也许最简单的方法是实现一个小的、静态的“serviceLocator”，它与spring相结合，在实体需要服务时查找实体请求的服务。这个服务定位器只是一个层，以避免您的实体耦合到Spring

---

传统上，存储库是域的一部分，对吗？至少，如果我们把《领域驱动设计》一书中的说明看作是传统的，那么存储库是由Spring管理的，我们如何注入这些存储库而不违反DI概念+1保存/更新/删除。。。操作不属于域对象本身。保存方法属于域对象，它是存储库保存的委托。如果将保存移动到存储库服务，则业务/服务层将调用存储库来保存转向服务分层体系结构的域。我想我必须开始阅读DDD，以明确我的概念