Should we always use Domain Model?
During the discussion about Domain Driven Design at the Alt.NET conference I felt like the idea of the Rich Domain Model was being represented as the only way to design software but I don’t feel that this is the case.
As always in software we never have a silver bullet and there are times when Domain Model is not necessarily the best choice, just as there are times when OOP is not necessarily the best choice.
To quote from Martin Fowler’s Patterns of Enterprise Application Architecture
It all comes down to the complexity of the behaviour in your system. If you have complicated and everychanging business rules involving validation, calculations, and derivations...you’ll want an object model.
What are the alternatives?
Domain Model is not a silver bullet and Martin suggests two alternatives when a model driven approach may not be the best choice
-
Transaction Script - The best thing about this is its simplicity. It is easy to understand as all the logic is in one place and it is a good choice for applications with a small amount of logic.
-
Table Module - This is a database driven approach with one class per table. If the system you’re working on is using a very table-orientated approach to storing data then this approach may be a good choice.
I think in order to make a Domain Model approach work, everyone in the team (including QAs,BAs etc) needs to buy into the idea and you need some people who have experience in using it so that you can use it in a pragmatic way.
While we have some great tools and techniques available to us in the world of software it is important to remember what problem we are trying to solve and pick the appropriate tool for the job.
Updated I’ve edited the phrasing of this after conversation - I intended to refer to the Rich Domain Model concept used in Domain Driven Design and was presenting alternatives to this rather than to DDD as a whole.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.