Question

From DDD: Tackling Complexity in the Heart of Software (pg. 159/160):

When database schema is being created specificaly as a store for the objects, it is worth accepting
some model limitations in order to keep the mapping very simple

…

This does entail some sacrifice in the richness of the object model, and sometimes compromises have
to be made in the database design (such as selective denormalization), but to do otherwise is to
risk losing the tight coupling of model and implementation.

…

But it is crucial that the mappings be transparent, easily understandable by inspecting the code or
reading entries in the mapping tool.

…

When database is being viewed as an object store, don’t let the data model and the object model
diverge far, regardless of the powers of the mapping tools. Sacrifice some richness of object
relationships to keep close to the relational model.

I do understand that with simpler mappings the Data Mappers will be easier to maintain, less buggy etc, but I don’t understand why we could also risk losing the tight coupling between a Domain Model and DM’s implementation by making mappings between DM and Data Model complex.

Namely, when creating a DM, we should try to be oblivious of how non-domain layers will be implemented and what techologies they will use. And since Data Mappers resides within DAL ( thus outside the Domain layer ), how then could the complexity of a mapping between DM and Data Model ( and thus the complexity of Data Mappers ) have any impact on the coupling between DM and DM’s implementation?

Thank you

Answer 1

The quote is actually:

but to do otherwise is to risk losing the tight coupling of model and implementation

It is talking about the coupling of the conceptual model and its implementation (in code). This is not a discussion about data mappers and mapping data to the implemented model, but about how you can lose fidelity to the conceptual model when implementing it – in particular when you need to consider a database or other implementation details.