Dino Esposito: The O/RM and the chicken/egg dilemma

Hi, this is Dino Esposito. It’s been a couple of years since Microsoft Press published Microsoft .NET: Architecting Applications for the Enterprise (ISBN: 9780735626096; 460 pages), which I wrote with Andrea Saltarello. We also created a successful class out of the book and taught it countless times. As you can imagine, we’ve received a lot of feedback about some of the statements we made in the book and some of the positions we took on sensitive design points.

A frequent point of discussion is the software architecture version of the old chicken/egg dilemma. What comes first in the design of a successful application: the database or domain model? As usual in software architecture, the most appropriate answer is, “It depends.” However, the fact is that nearly everybody draws conclusions strongly biased by his or her background. And the original question remains not just unanswered but blurs more every time. This post is an attempt to make sense of the “It depends” statement applied to databases and domain models.

Most software exists to model in some way some business process. Or software exists to “model” a “domain” that people use for their business. This is a fact, but it is still way too abstract to make it a definitive statement in favor of the domain model.

Software exists to model a business process in order to provide an effective solution. “Effective” is another popular blanket term turned to in any given context. “Effective,” however, refers to a solution that does the trick the customer really needs in the way the customer needs. Common adjectives we can use to better explain what doing-the-trick means are fast, scalable, and extensible.

For about two decades we built software systems around a database and we argued about the ideal place to store the business logic. In any case, we modeled the domain in terms of relational databases. For many years, this was just fine for any sort of problem.

Developers dealing with very complex logic inevitably feel the need to add a more abstract layer on top of the database schema. The domain model doesn’t replace the database: it’s simply an abstraction layer that architects use to break down the problem into more digestible pieces. Using a domain model, architects can reason about the model without the constraints of a relational model. At this stage, it’s purely modeling.

The domain model must be persisted to some database, and this is where misunderstandings arise.

Domain and database are two equally important components of the system; they must work together. You can’t design the model ignoring the database; you can’t force to model the domain because of the database. It’s a deal that must be reached, and trade-offs must be found.

What’s the role of the object-relational mapping (O/RM) in this context? As we state in the book, the O/RM is merely a facility. It’s not mandatory, and it should not rule the structure of databases or models. If you let the O/RM command you, you’re lost. This is the real sore point.

You can have a domain model to expose to services and presentation and a database where you store data. The content of the database flows into the domain model (and back). The structure of the database is aware of the model and vice versa. The code that flows data between the model and the database can be written by you (via stored procedures, for example) or by some O/RMs. O/RMs, though, tend to be invasive and dictate too many development and design aspects.

O/RMs can save a lot of work and are a great tool indeed, but poor understanding (or just poor explanation) of their role helps create the domain/database dilemma and makes it harsher every day.