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.

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 question – What is the purpose of this data to the enterprise? In what context is it valuable?

Entities come with baggage. They stop us from thinking YAGNI at an architectural level. If we don’t need the data, we shouldn’t persist it. If we don’t need an event, we shouldn’t publish it. If a tree falls in the forest, unless it serves a purpose in the forest service business capability, it will not publish a sound event.

The hardest part of SOA is getting past our preconceived notions of what business is all about. We have them at many levels. We have baked them into relational databases and we have “anemic domain” models in our heads from years of repetitive system design.

To get SOA right, we first have to get over ourselves.