The Ideal Domain-Driven Design Aggregate Store?

by zerd • 12 years ago

30 26 12 years ago

califield• 12 years ago

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

bdavisx2• 12 years ago

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• 12 years ago

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.

daigoba662• 12 years ago

In one project I was able to achieve an identical "ideal ddd aggregate store" using MSSQL.

- The aggregates are XML serializable entities persisted into tables using the XML datatype (fairly comparable to PostreSQL's JSON datatype).

- MSSQL has numerous methods for querying, updating, and reading from XML typed columns. They're certainly clunky, but they do work.

- To simplify querying and indexing, we created computed columns with a user defined function to query from the XML column. By marking these columns as persisted, the UDF is only executed and the column updated when the row is written. And as persisted, the computed columns can be included in normal indexes to improve performance.

A lot of folks may scoff at using XML, and especially MSSQL's XML datatype. But I will say that it works. And after you've built a simple foundation, developing your aggregates and working with them almost becomes a breeze.

And as far as XML versus JSON... it almost doesn't matter in this case.

jchrisa2• 12 years ago

This sounds like the approach used by Couch-style incremental map reduce. For each JSON document, run a JavaScript function to determine the document's contribution to the map reduce index. (Basically a user-defined column with optional custom aggregation.)

So you can easily normalize multiple incoming JSON types to a single index (eg mix JSON data from different APIs into a single "column", etc.)

And that's not even getting into the reduce side. From [1] "if documents represent your company’s financial transactions, a view can answer the question of what the spending was in the last week, month, or year."

[1] http://guide.couchdb.org/draft/views.html

daigoba662• 12 years ago

It's very much the same pattern.

Also check out RavenDB (http://ravendb.net/). It's another JSON document database with JavaScript powered map/reduce indexes. One caveat is that RavenDB updates its indexes async. It's a type of eventual consistency. That means that after a write, an index may not immediately have the updated data. Depending on the application, this may or may not be acceptable.

skrebbel• 12 years ago

Does anyone have real field experience with using Postgres as a JSON data store like this? Most notably, I'm curious about migrations and evolutionary database design.

With oldschool relational SQL, you'd write migration scripts that alter the database schema and also port the data.

It is my understanding that many people who use MongoDB and the likes just tend to keep old data as it is, and make sure that the code just supports older versions (like missing keys, etc). So you'd get code like

    record = db.get(...)
    if(!record.subtype) record.subtype = "defaultSubType"

Or maybe something smarter with a version number in each document.

I prefer to not write that code, but I also really like the idea of (ab)using Postgres JSON stores, with identically structured JSON for each row.

Did anyone ever write JSON data migrations with something like Postgres? Or Mongo? If so, how? PL/pgSQL? Load everything into backend memory and manipulate it and store it back? What if you want to split aggregates? (i.e. you have 1M "Person" JSON blobs and want to split it into 1M "Person" blobs and ≤1M "Address" blobs)

netghost• 12 years ago

Just write ordinary migrations with updates and such. I think you should able to manipulate the JSON without too much bother. Here's the functions available for JSON: http://www.postgresql.org/docs/9.4/static/functions-json.htm...

Here's more about the JSON type in Postgres: http://www.postgresql.org/docs/9.4/static/datatype-json.html

There's also Postgres' hstore, which I believe now shares the same backing as JSON(B), but may have a different API.

ExpiredLink4• 12 years ago

I'm amazed that people still refer to DDD ('OOP on steroids').

rgvcorley• 12 years ago

Why?

ExpiredLink4• 12 years ago

Hard to describe it in one sentence. Just look at the various DDD resources. It's difficult to put together the meaning of the numerous concepts introduced (and often just renamed) by Evans. The core idea is - just like in OOP - to pack data and most business logic into domain or entity objects. IMO, a questionable approach.

socceroos2• 12 years ago

Do you mean that the approach of DDD feels obsolete or antiquated? I'm genuinely curious...

antigremlin• 12 years ago

From my recent experience on a real project DDD inspires very rigid thinking sometimes on the boundary of being religious (e.g. the quest for pure Values and Aggregates eclipsing the problem domain understanding).

And for a regular "aggregate" entity I would never prefer a JSON storage to a data mapper with SQL (as long as you have an option to use SQL). You should have a reason for JSON and such, otherwise it's just NoSQL hype.

kitsune_2• 12 years ago

I say that DDD sounds nice in principle, and in blog posts, and in books, but I have yet to see that magical fairy land be implemented in the real world.

Aggregates (and drawing their boundaries), especially when combined with domain models backed by an ORM must be one the more impractical programming concepts that I've met in my life.

P.S. I also don't trust programmers who write (enterprise) books for a living.

dm3• 12 years ago

It's neither obsolete, nor antiquated. People in this thread seem to conflate DDD and OOP which is understandable given that 90% of DDD resources target the typical enterprise Java/C# setting.

The truth is, DDD consists of two parts: tactical patterns, such as Entity, Value Object or Aggregate Root and strategic design patterns such as Ubiquituos Language, Bounded Context or Context Maps. Tactical patterns are much easier to understand and apply, but most of the benefits claimed by DDD are provided by the application of strategic design.

Sadly, most people starting with DDD focus on the tactical patterns and technology, then get demotivated when the benefits do not appear.

boothead• 12 years ago

I think it would be better to refer to it as "Functional Programming at Scale" :-)

dustingetz• 12 years ago

Datomic meets most or all of these criteria by design, per my understanding, most importantly not having an OR impedance mismatch while preserving ACID

kitsune_2• 12 years ago

Most definitely, EDN is obviously a nice format to work with if you already use Clojure.

Also, I think what all the DDD and Hibernate advocates failed to articulate when they hyped their paradigms 10 years ago was that their model of programming simply doesn't work that well. As soon as you introduce an ORM your class design will have some inane arbitrary limitations that actually fight the "principles of DDD" on every level. You end up with convoluted domain models and services and a huge monstrous cathedral of abstraction.

The Ideal Domain-Driven Design Aggregate Store?

Related Stories