Domain-Driven Design and Modules
This book has taken me awhile to read. Not because it was a hard read, but because its really not commute friendly when your also carrying a Macbook around everyday. Anyway, finally after starting this book on a recent flight to New York, I’m happy to be able to finally blog some thoughts.
One Team, One Language (page 32). It’s hard not to disagree with a lot of this. From my line of work, communication is key to the solutions being built and delivered to the business.
“A document shouldn’t try to do what he code already does well” (page 38) is I would say very XP 
“Hands on Modellers” (page 61) is valid, and bears a striking resemblance to the architecture who needs to be hands one, else how can he design the system? I could never 100% given up coding, being close to the rock face every now and again helps to keep ones edge, and clarify thoughts and actions 
Ubiquitous Language I think is first mentioned on page 64, and is pretty central to the whole book.
Separation of concern (page 69) appear to be very relevant in solution delivery these days. It therefore quite appropriate that Eric’s Layered Architecture (page 69) touches on the subject. I wonder how many people reading this posting have a domain layer (page 75) in there currently project?
Services (page 105) in Eric’s view provide three characteristics of which domain geared interface and stateless are two. Get the book to find the third.
The usual factories (page 141) and repositories (147) are discussed in The Lifecycle of the Domain Object (chapter 6). To be honest, this isn’t anything new for those software engineers who have bothered to stay in touch with good design practices and patterns.
To be quite frank, page 179 probably generated the most thought – infrastructure-driven packaging. Here’s the thought (assuming I have understood what Eric has written): If you look at most Prism implementations, the assemblies are geared towards each layer in the MVVM pattern. Hence in the case of a trading application you could have the trade blotter classes spread across a minimum of four assemblies, which high coupling. Whereas what Eric is proposing is to package based on cohesive concepts – maybe the blotter classes should all be in once assembly, but appropriately namespace’d ? Having seen various Silverlight projects that has 50+ assemblies, it does beg the question of if we aren’t getting into assembly hell. Modules and class dependencies are touched on again on page 266.
Followed closely behind the above point, Supple Design (243) rings true on the point regards over-engineering in the name of flexibility. Excessive layer of abstraction and indirection came sometimes cause more problems than they solve. Likewise, Intention-Revealing Interfaces (I quite like the phrase – 247) rings home the importance of naming methods appropriately.
I can see Side-effect-free functions (page 251) and immutable value object becoming important in the parallel programming age we are entering – design by contract (page 255)
Refactoring Towards Deeper Insight (page 321) and particularly the scope and sleep point and relevant to all. Likewise the point on Timing (324) is very relevant, and probably rings a few bells with colleagues in the area of distributed caches. The final paragraph of page 326 should probably be read by project managers
Eric offer some thoughts on where to put your top talent (page 402) – on the Core Domain. I’ve known projects where this has been the reverse 
A Tale of Two Time Zones (page 410) just made me laugh for obvious reasons…..
You probably want a domain vision statement (page 415) as early as possible on a project to provide focus on the domain model.
Large scale structure is a problem that a few of us know well. Page 481 reminds us to constantly rethink large sale structure throughout the life of the project to ensure evolving order.
Six Essentials for Strategic Design Decision Making (page 492) offer some obvious but often forgotten points. I particularly liked the first – decisions must reach the entire team I imagine a number of us can think of decision that when made took weeks if no months to finally reach all members of a team.
In summary the book was an interesting read, however so much of its content was obvious and like so many books, the later section wasn’t as good as the first. If anything I think the module view should cause some debate, which is always a good thing
I disagree that much of the content is obvious. Then again, I read it a while ago when it first came out in like 2004. We also studied it at our design patterns study group. Perhaps so much of the material is permeating the software development community now that much of it has become common practice. People nowadays think the GoF patterns are obvious. But in 1997 (or so), we had a study group for going over and getting a deeper understanding of patterns. These patterns are so much a part of everyday coding that it’s easy to see why one might think they’re obvious. I can imagine someone thinking it stupid to catalog something like the Iterator pattern.
I’m certain it’s a “deep” book and not filled with the obvious. But I’d have to go back and dig in order to really debate this.