持续性的无知和DDD现实 [英] Persistence ignorance and DDD reality
问题描述
我正在尝试不费吹灰之力实现完全有效的持久性无知.不过我有很多问题:
最简单的选项
这真的很简单-可以像在SOA中那样用Spring Data批注对实体进行批注吗(但是让它们真正地执行逻辑)?除了不必在实体中真正使用PI原理的实体中使用持久性注释外，还有什么后果?我的意思是Spring Data确实是这种情况-它提供了不错的存储库，可以完成DDD中的存储库应做的事情.问题出在实体本身上……
更难的选择
为了使实体不知道其操作的数据来自何处，自然可以通过构造函数将该数据作为接口注入.另一个优点是我们总是可以执行延迟加载-例如，默认情况下，我们在Neo4j图形数据库中具有延迟加载.缺点是，聚合(由实体组成)即使不使用它们也会完全了解所有数据-可能会由于数据完全暴露而导致调试困难(DAO就像聚合一样，是分层的).这也将迫使我们对存储库使用某些适配器，因为它们不再存储真实实体了.而且任何转换都是丑陋的.另一件事是，如果没有这样的DAO，我们无法实例化Entity-尽管可能存在领域中的内存实现...再次，更多层.有人说注入DAO也会破坏PI.
最困难的选择
可以将实体包装在决定数据从何处来的惰性加载器周围.它既可以是内存中的，也可以是数据库中的，并且可以处理任何需要事务处理的操作等等.虽然是复杂层，但在某种程度上可能是通用的……?在此处
您知道其他解决方案吗?或者也许我在提到的东西中缺少了一些东西.请分享您的想法！
作为适当的域建模的副作用，我(几乎)免费实现了持久性无知.
尤其是:
- 如果正确定义每个上下文的边界，则无需延迟加载即可获得小实体(在DDD项目中实际上变成了反模式/代码气味)
- 如果您不能简单地在存储库中使用SQL，请将一组DTO映射到您的数据库模式，然后将它们用于工厂中以初始化实体类.
在DDD项目中，持久性无知与域模型本身相关，而与存储库，工厂和其他应用程序代码无关.确实，您将来不太可能更改ORM和/或数据库.
领域模型的持久性无知背后的 only (但非常强烈)理性是关注点分离:在域模型中，您应该 only 表示业务不变量！持久性是基础设施问题！
例如，在没有持久性无知(并且没有延迟加载)的情况下，域模型应该处理db中可能出现的异常，它的复杂性会增加，并且业务规则会被技术细节所掩盖.
I'm trying to implement fully valid persistence ignorance with little effort. I have many questions though:
The simplest option
It's really straightforward - is it okay to have Entities annotated with Spring Data annotations just like in SOA (but make them really do the logic)? What are the consequences other than having to use persistance annotation in the Entities, which doesn't really follow PI principle? I mean is it really the case with Spring Data - it provides nice repositories which do what repositories in DDD should do. The problem is with Entities themself then...
The harder option
In order to make an Entity unaware of where the data it operates on came from it is natural to inject that data as an interface through constructor. Another advantage is that we always could perform lazy loading - which we have by default in Neo4j graph database for instance. The drawback is that Aggregates (which compose of Entities) will be totally aware of all data even if they don't use them - possibly it could led to debugging difficulties as data is totally exposed (DAO's would be hierarchical just like Aggregates). This would also force us to use some adapters for the repositories as they doesn't store real Entities anymore... And any translation is ugly... Another thing is that we cannot instantiate an Entity without such DAO - though there could be in-memory implementations in domain... again, more layers. Some say that injecting DAOs does break PI too.
The hardest option
The Entity could be wrapped around a lazy-loader which decides where data should come from. It could be both in-memory and in-database, and it could handle any operations which need transactions and so on. Complex layer though, but might be generic to some extent perhaps...? Have a read about it here
Do you know any other solution? Or maybe I'm missing something in mentioned ones. Please share your thoughts!
I achieve persistence ignorance (almost) for free, as a side effect of proper domain modeling.
In particular:
- if you correctly define each context's boundary, you will obtain small entities without any need for lazy loading (that, actually becomes an antipattern/code smell in a DDD project)
- if you can't simply use SQL into your repository, map a set of DTO to your db schema, and use them into factories to initialize entity classes.
In DDD projects, persistence ignorance is relevant for the domain model itself, not for repositories, factories and other applicative code. Indeed you are very unlikely to change the ORM and/or the DB in the future.
The only (but very strong) rational behind persistence ignorance of the domain model is separation of concerns: in the domain model you should express business invariants only! Persistence is an infrastructural concern!
For example without persistence ignorance (and with lazy loading) the domain model should handle possible exceptions from the db, it's complexity grows and business rules are buried under technological details.
这篇关于持续性的无知和DDD现实的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
