[califield]

The author doesn't mention the go-to option in this scenario: write a data mapper[1] to dehydrate your object.

While I'm a huge proponent of PostgreSQL and the hstore[2]/JSON column types (hstore column type is not mentioned but it existed way before JSON columns), it's still more common to use PostgreSQL in a primarily relational fashion and the author could have touched on that more before giving us the scoop on the new shiny stuff.

[1] http://martinfowler.com/eaaCatalog/dataMapper.html [2] http://postgresguide.com/sexy/hstore.html

[bdavisx]

I think it's a general concensus that a "data mapper" isn't much better than an ORM (obviously a form of data mapper). While you can write a data mapper that is less intrusive than a typical ORM, it's still not as nice as using a schemaless type of store such as JSON.

[mrottenkolber]

Not a OOP wizard but from my experience ORMs tightly integrate with both your objects and your DB. So a "DataMapper" would indeed be my choice for a sane "persistence-layer" assuming:

* The objects don't know about the mapper * The DB doesn't know about the mapper

The "ideal DDD aggregate store" with a "schemaless type of store such as JSON" on the other hand binds the implicit schema to your objects. Seems more interlocking and less modular to me.

E.g. I'd rather settle on "this Mapper is the bridge, whatever it does" instead of "the bridge is implicitly defined by however I entangle objects and store".

Boils down to the old inheritance vs composition.

[bdavisx]

I'm not disagreeing, but I guess I was comparing a relational schema to a JSON "schema".

I do agree a mapper is less intrusive than either. I think I have a bias right now because I've been working on an event sourced model that's using JSON as the serialization mechanism :).