Domain driven design, and different kinds of databases
While reading Eric Evans’ excellent Domain Driven Design, I was put in mind of one of Dave’s recent blog entries and what is being called The Great Application/Integration Database War of Attrition (by absolutely no-one).
The debate has been sparked by a couple of Ruby gurus (David, Alex) who object to triggers and constraints in the database, on the grounds that its role is merely to store data. David Heinemeier Hansson says
I consider stored procedures and constraints vile and reckless destroyers of coherence. No, Mr. Database, you can not have my business logic.
To them, the constraint logic goes in the ORM layer, which in the case of Ruby on Rails is Active Record. To exacerbate the controversy, David distinguishes application databases and integration databases, saying he is only referring to application databases — those that serve only a single application.
Dave (among many others) takes exception to this on at least two counts: that a database is often the natural place to put such constraints, even if they are business contraints, and that application databases never exist for long — the database will always end up being reused, or the application expanded, because the business’s needs always evolve.
It turns out that some of what Eric Evans says is relevant to this debate. Eric talks about putting the domain knowledge into a separate layer — the book is less about why this is a good idea, and more about how it can (and should) be achieved in practice. Naturally, he doesn’t claim this approach is appropriate to every scenario. In particular he spends some time comparing this layering to the “Smart UI” approach, in which the logic for UI, application, domain and infrastructure is all mixed together. His point is that there is a time a place for this, and that creating a domain layer in a small application can cause unnecessary overhead. This seems fair, and he is effectively saying there are isolated applications on the one hand and integrated applications on the other. His is reflecting the distinction between isolated databases (application DBs) and integration DBs.
As an aside, I’d agree with Dave, that an application database almost never exists in a real organisation. That’s not to say they don’t exist, just that you’re unlikely to find them in a half-serious enterprise.
However, the application/integration DB discussion is really just a distraction. There are two issues that really highlight a major flaw in the arguments of David and Alex.
The first problem is how an application is perceived. In arguing for constraints to be held outside the database, and inside the Ruby on Rail application, Alex says:
Rails is the author of the data. As an author, it uses the RDBMS to manage that data in a relational fashion. [...] Why should we tolerate RDBMS opinions on our data? We’re the masters, RDBMS is the servant, it should shut up and serve. End of discussion.
Alex thinks that the application is “us” while the database is “them”. And he doesn’t distinguish between different layers of the application. If he is to be fully in control of his applications, then he needs to take just as much responsibility of the database as the application code. Furthermore, it’s a worry that he’s talking about the application as one lump, not distinguishing between its layers. Probably he doesn’t perceive any layers, just as David is only talking about “application databases”. The whole software just a single indivisible entity.
None of this suggests a thoughful enterprise developer.
The second problem is an understanding of business logic, and this is highlighted particularly in Eric’s book. There the discussion is of separating the domain layer (where the business domain is expressed, along with the business constraints, though there’s nothing to say other constraints can’t appear in the database) from the infrastructure layer (which handles persistence and other low level services). The ORM is very squarely in the realm of the infrastructure layer, yet to Alex and David this is where the business logic goes. Again, it doesn’t speak well of them that they consider putting business logic inside a mapping tool.
So overall I’m with Dave’s team in much of this discussion. But I’d say there are issues here which are much deeper than where to put your constraints — it’s about how you design software which is anything other than trivial.
Much of this has come from Eric Evans’ book, and I’d strongly recommend it to any developer working in OO in an enterprise environment.
