We were unable to load Disqus. If you are a moderator please see our troubleshooting guide.
Hi miro,
It's an open-ended question. In SQL or NoSQL?
1. For SQL. As we traditionally store normalised data, then DDD aggregates wouldn't exist at the DB level (an aggregate would be converted to a bunch of tables). Though, aggregates may exist at the ORM level (depending on the ORM) or Domain level. There are many tools for data mapping between DDD aggregates in the Domain level and normalised DB tables. It's not a smooth ride and I talk about that in the next post – Two reasons to NoSQL (things like object-relational impedance mismatch can get very annoying).
2. For Document NoSQL (not Graphs, Columnar, etc.). Undoubtedly, it's a better fit for storing DDD aggregates (again a reference to Two reasons to NoSQL). Overall, if the 7 reasons listed here is not a problem for you team, then NoSQL is the way to go.
I'm not advocating for using SQL or NoSQL. I see them just as tools in the dev's tool-belt. My approach – understand pros and cons of each and apply them accordingly.
How do you store DDD aggregates ?