A quote about isolated data stores from Eric Evans

I need to keep this quote around so where better than my blog?

“For as long as I can remember, I’ve been advocating that a team that’s developing some complex piece of logic should have their own isolated data store and not have to share some huge database that has some kind of mishmash of different people’s ideas of what the data should be and so forth.”

(Eric Evans, “DDD & Microservices: At Last, Some Boundaries!” GOTO Berlin Dec 2015 (gotober.com) https://www.youtube.com/watch?v=yPvef9R3k-M)

This is such a difficult thing for so many developers to buy into. I frequently share a story about Eric trying to ease me out of a near mental meltdown, explaining to me when I was struggling with this (& I am paraphrasing and possibly adding some of my own comprehension at this point) that you have to pay the price somewhere and often its just less painful to solve the problem of having data in different places that needs to connect once in a while than it is to deal with the complexity of a system that tries to provide all answers to all of the problems. We have patterns to solve the “connect the data once in a while” problem (e.g. message queues).

I admit that I have to advise people to aim for this but it’s often not practical (or cost-effective) so if we’re talking about relational databases then we can at least isolate with schemas. But I do try to start with “separate database” and work our way backwards from there if it’s just not doable (or if the person or team I’m talking to looks like they are about to murder me). However each step backwards comes with a price. You just have to choose – pick your poison. As long as you are doing so with the right information at hand to make those decisions & choices, I think that’s the most important part.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!  

One thought on “A quote about isolated data stores from Eric Evans

  1. “… But I do try to start with “separate database” and work our way backwards from there if it’s just not doable (or if the person or team I’m talking to looks like they are about to murder me)…” LOOOOL great comment! and I can relate to the “killing” each other part during modeling seasons LooL

    The classic example is the relationship between Sales and Products when building typical LOB apps. And as some one who started building apps during the early 90s I usually modeled it as one big Database with 1:1 relationship between SaleLineItem and Product.

    However, now I find it much more easier to model it as two separate (Sales, and Products) databases.

    And when a “Sale”transaction occurs we capture a “ProductSold” projection from the Products DB that we save with the Sales data !!!

    I guess there are many motivation for the separate databases but one motivation is the sheer amount of data and product information that needs to captured for Product items and “SoldProduct” projection!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.