Domain Driven Design
Listen to this article
I spent many years writing software that was essentially procedural in nature with transaction scripts accessing a database through very simple active records. Since I've come to appreciate the benefits of a rich domain model I've wished I had the ability to communicate this to others.
So I was excited when I heard about the book Domain Driven Design.
It's nicely written. A good mix of code, diagrams, anocdotes and I particularly like the transcripts of conversations from actual modelling and design sessions. Lots of examples, rules of thumb and hints and tips here and there. It reminds me of Pragmatic Programmer in the way it reads.
Points I've particularly liked:
- Model-driven design he says "discards the dichotomy of analysis model and design to search out a single model that serves both purposes." Something I've always felt since reading Analysis Patterns. As the author points out, this is very hard to do but well worth the effort.
- The good old manufacturing metaphor where highly skilled engineers design and less skilled laborers assemble the products has "messed up a lot of projects for one simple reason--software development is all design." All right! Rock on! I'm printing that out in 70pt font and sticking it up on the wall of my favourite enterprise architects office!
- "If an unsophisticated team with a simple project decides to try a MODEL-DRIVEN DESIGN with LAYERED ARCHITECTURE, it will face a difficult learning curve." I've recently pondered this as I've struggled with bringing teams of developers up to speed with these concepts. I've wondered whether I may be making matters worse before they, hopefully, get better.
Things I've disliked:
- As Doug points out in his review, I too was a bit surprised by the "Manager" classes. Seems to defeat the whole purpose of rich domain models but as I haven't finished yet and, the author promises to address this later in the book (fingers crossed) I've chosen to ignore it so far.
- The book is rather verbose I'm sad to say. I got into the first section and started to stall! It was very hard to get motivated to read the rest of the book.
All in all not a bade book. Someone definitely needed to write about it but as I mentioned, it was a little verbose for my liking. But I did finish it and I'd have to say that it was probably worth it.
Comments
Actually, what I DISliked the most about Domain Driven Design was the claim that analysis and design are the same. Poppycock. Analysis is an inferential process of trying to understand the problem to be solved, while design is a creative process of producing a solution to the problem. Analysis is listening, Design is talking; Analysis is reading, Design is writing. Analysis and Design are different processes with different goals, and require different skills. (See the link below for my own review of DDD.)
Posted by: Doug | December 15, 2003 10:38 AM
Hey Doug. Just read your review. I haven't finished the book so I'm hoping at some point he moves away from all the "Manager" classes too. Like you, I was a bit surprised at first to be reading a book on Domain Modelling only to find "Manager" classes.
Posted by: Simon Harris | December 15, 2003 03:29 PM
P.S. I'm still waiting for my copy of Streamlined Modelling to arrive :-)
Posted by: Simon Harris | December 15, 2003 03:31 PM
Hey Simon. I'm taking my second look at DDD and in the process scrounging around in the community for some success stories in forming a Ubiquitous Language - one that involves analysts (!) and goes as far as describing scenarios in the language.
I find it a struggle just to get development teams to _want_ to form and evolve a deeply expressive model; involving analysts in the process of forming that model seems a huge hurdle. Maybe us geeks are generally too introverted to continually discuss and refine a model. Maybe I need to find more convincing arguments in favour of DDD approaches to challenge those still engrained in pumping functionality out over the relatively indirect benefits DDD offers.
For instance, an argument I've recently struggled with is trying to convince a development group to adopt a non-framework orientated package structure (like com.blah.action, com.blah.form, com.blah.domain and etc.). It's an argument that's tough to win in the face of a team focused on pumping out stories and avoiding the relative distractions of quality/comprehendability/maintainability.
Any chance you know of any local success/inspiration stories?
Posted by: blondie | March 7, 2006 10:52 PM