In Martin Fowler’s article OrmHate, he states the following:
If you have an application problem that maps well to a NoSQL data model – such as aggregates or graphs – then you can avoid the nastiness of mapping completely. Indeed this is often a reason I’ve heard teams go with a NoSQL solution. This is, I think, a viable route to go – hence my interest in increasing our understanding of NoSQL systems. But even so it only works when the fit between the application model and the NoSQL data model is good.
Assuming that the domain model maps well (1:1) to a corresponding NoSQL document, are there any pitfalls to eliminating the persistence model<-> domain model mapping altogether? It seems this would be a violation of SRP as now the domain model has the additional responsibilities of dealing with persistence, on top of handling business logic.
Fowler is only referring to the mapping between the in memory representation of the document and the document itself, not the persistence of changes made to the representation. You would still need to separate the responsibility of persistence from the domain model. The key here is that you would have no mappings between those two responsibilities, so separating the responsibilities would be easier, more straightforward.