It's not all relational

For decades enterprises have understood the database as the true technical authority. No matter what insanity we application developers create, the relational database, by enforcing constraints and referential consistency, by disallowing nulls and protecting unique values with its transactions and ACID principles – it keeps the chaos at bay and gives us Truth with a capital T.

But nothing is free. Requiring all domain truth to be expressible with a single model, the relational entity store, is like painting the world with only primary colors. The subtleness of the domain is lost. Meaningful questions are obscured by the checklist of entity relational questions. Should the customer’s name be 50 characters or 100 characters? Should it be non nullable? In what aggregate does it belong? These questions hide more important questions – How is this data used in the enterprise? In what context is it valuable? Not all concepts fits nicely into the relational model. Modeling businesses processes requires us to fit the best abstraction to the problem.

Our overreliance on relational data models comes with baggage. One of the hardest parts of good service oriented architecture is getting past our preconceived notions, built from years of repetitive system design, that all businesses data is best modeled relationally.