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.
How did the first team ever succeed at DDD when there was no one who had experience using it and there could be no buy in until the idea was understood.
I think you must distinguish between when there is a good technical argument and a good social argument. Obviously the domain of your app must play some part in your decision and not just whether or not you have buy in.
Likewise you could have a very table oriented way to storing your data, but that does not mean it is the way you should be storing your data.
Figure out what are the parameters of your app, and what are the capabilities of the people you will be working with.
Don't base it solely on whether you have buy in or whether it is already being done another way. as you suggest above. There are objective pointers to use.
and by the way, can people stop suggesting that anything was ever called a silver bullet by anyone. Can we just assume that anyone who does suggest that anything is a silver bullet is too stupid to merit a response? Then we could concentrate on more worthy discussions.
Jeff Santini
19 Sep 08 at 12:21 pm
Fair points. What would you suggest as pointers that would indicate whether or not DDD is likely to be a successful approach?
Re: the silver bullet idea…I just meant that it seemed (in the discussion at the conference) that it could be applied to all situations and other approaches were 'less worthy'. Of course that may just be my perception but I thought I'd put it out there.
Mark Needham
19 Sep 08 at 12:40 pm
I actually think the relational-object complexity aspect can be oversold.
Using Castle ActiveRecord, and so using attributes to control persistence, and binding those "domain" objects directly to the GUI is incredibly simple. Even if your DB and domain don't match it can work as there is some flexibility there.
Obviously if its a shared DB, or you don't control the DB, then it is more work but even then you can bridge the gap between relational and domain relatively easy when the problem domain is relatively small and/or simple. In such cases you can sacrifice some domain model quality to make the mapping possible/easier.
However if you want to do DDD "properly" you really have to use not only the patterns but the ideas including the analysis/design. That adds a lot of work on its own, work thats very worthwhile but not necessarily needed in all cases.
So I actually think that the core patterns (factory/service/aggregate/specification/repository/entity/value object) can be used in many more cases than the concepts.
Colin Jack
19 Sep 08 at 1:07 pm
I think you may have made a confusion, Mark.
You've presented as alternatives techniques that are at the same level as the Domain Model pattern, not Domain-Driven Design.
It is very hard to have DDD without the Domain Model pattern but you don't have to use DDD just because you have a Domain Model. DDD is about using business language in the software constructs, Domain Model is just about having proper objects (and not just functions and data structures) as the business logic holders.
So, in the end of the day the answer to your question would be 'no', but not just because you could use transaction scripts or table gateways but because you could have a Domain Model that's not designed after DDD principles.
cheers
Phillip Calçado "Shoes"
19 Sep 08 at 2:33 pm
@Phillip – You're right, I think I have phrased this quite poorly – I guess I am more talking about the Rich Domain Model idea within Domain Driven Design rather than DDD as a whole. That's what the discussion was around and there seemed to be the suggestion that having the rich domain model was the only way to do it.
As you mention I haven't seen DDD done when there wasn't a domain model in use as well.
So in a way there are almost two questions I was pondering – what are the alternatives to DDD and what are the alternative to using the domain model? It would be interesting to hear your thoughts on the former.
Mark Needham
19 Sep 08 at 4:47 pm
[...] friend Mark Needham wrote a blog post on the Domain Model pattern and Domain-Driven Design recently. He changed a bit the contents but the original question was: Should we always use Domain-Driven [...]
Object-Oriented Design: Which, How and What at Fragmental.tw
22 Sep 08 at 3:48 pm