最简单的选择
它真的很简单 – 是否可以像在SOA中那样使用Spring Data注释注释实体(但是让它们真正做到逻辑)？除了必须在实体中使用持久性注释之外还有什么后果,这实际上并不遵循PI原则？我的意思是Spring Data的情况确实如此 – 它提供了很好的存储库,可以完成DDD中的存储库应该做的事情.问题在于实体本身呢……
更难的选择
为了使实体不知道它所操作的数据来自何处,通过构造函数将该数据作为接口注入是很自然的.另一个优点是我们总是可以执行延迟加载 – 例如我们默认在Neo4j图数据库中.缺点是Aggregates(由Entities组成)将完全了解所有数据,即使他们不使用它们 – 可能会导致调试困难,因为数据完全暴露(DAO将像Aggregates一样分层).这也会迫使我们为存储库使用一些适配器,因为它们不再存储真实的实体……并且任何翻译都是丑陋的…另一件事是我们不能在没有这样的DAO的情况下实例化实体 – 尽管可能存在 – 域中的内存实现……再次,更多层.有人说注入DAO确实会破坏PI.
最难的选择
实体可以缠绕在一个懒惰的加载器上,它决定了数据的来源.它既可以是内存中也可以是数据库内,它可以处理任何需要事务的操作等等.虽然复杂的层,但可能在一定程度上是通用的……？读一读here
你知道其他任何解决方案吗？或者也许我错过了所提到的东西.请分享你的想法！
作为正确的域建模的副作用,我实现了免费的持久性无知(几乎).特别是：
>如果你正确定义了每个上下文的边界,你将获得小实体而不需要延迟加载(实际上它成为DDD项目中的反模式/代码气味)
>如果您不能简单地将SQL用于存储库,请将一组DTO映射到数据库模式,并将它们用于工厂以初始化实体类.
在DDD项目中,持久性无知与域模型本身相关,而不是与存储库,工厂和其他应用程序代码相关.实际上,您不太可能在将来更改ORM和/或数据库.
持久性忽略域模型背后唯一(但非常强大)的理性是关注点分离：在域模型中,您应该只表达业务不变量！坚持是一种基础设施问题！
例如,如果没有持久性无知(以及延迟加载),域模型应该处理来自db的可能异常,它的复杂性增加,业务规则被隐藏在技术细节之下.