Today I finally cracked open the Domain Driven Design book, from Eric Evans.
Sifting through the preface of a textbook can be a tedious exercise, and the DDD book was no exception. It’s not that the information in there isn’t interesting or valuable, it’s that it rarely makes much sense when you first begin reading a book.
That said, there are a few things that caught my eye, and I’m glad the author included them. For starters, the book has an explicitly defined two-fold premise:
1) For most software projects, the primary focus should be on the domain and domain logic.
2) Complex domain designs should be based on a model.
Definitions are not provided for the domain and model terms, and that’s something that I’ve always wondered about–because I tend use those terms without additional clarification fairly often myself. So I guess I’ll need to start with my own understanding of what these words mean, and then adjust as I read further.
When I use the word domain, I’m usually referring to the actual rules, information, events, processes, and roles that a software system needs to deal with. It’s the stuff that has a direct mapping to a business, or a customer, etc.
When I use the word model, or hear others use that word, I think of an idealized high level representation of some system which typically has at least one corresponding representation in the real world. Theoretical models exist too, but most interesting models for practitioners are the descriptive sort that are related to something that’s either already built or is in the process of being built.
If the author is using vocabulary that’s at least somewhat compatible with my own, then I have no trouble accepting the books premise. That the primary focus of software development should be to understand and define the “real world” problems that are being solved, and that once those problems get complicated enough, you need some higher level representation than source code to communicate ideas with.
I also like that the author listed a couple prerequisites for DDD, which can help the reader determine if the techniques and recommendations would be relevant to them or not.
The two prerequisites that Evans lays out are that at a minimum, DDD requires iterative development and a close relationship between developers and domain experts.
These requirements makes intuitive sense to me. Feedback loops are severely constrained when design must be done in complete up front without revisiting the same ground over and over again, and models produced by developers who only have a shallow understanding of the underlying business and customers their software is supporting will at best only coincidentally align with the essence of the job to be done.
(Side note: One thing I’m not sure how I feel about is that the author repeatedly mentions Extreme Programming (XP) in the preface. He says something along the lines that understanding XP principles will help you appreciate the underlying context of the work, but that you don’t need to be familiar with them or practice them yourself to make good use of DDD. This seems to fit me just fine, as someone who cherry-picks bits and pieces of named methodologies at will… although it does ring some alarm bells of Holy Thinking that may appear later on in the work. I hope I’m wrong about that!!!)
To end on a positive note, the following paragraph was by far my favorite part of the preface. It expresses something that I can deeply relate to from my own experiences, and I really appreciate how well the author has stated it:
Valuable models do not emerge immediately; they require a deep understanding of the domain. That understanding comes from diving in, implementing an initial design based on a probably naive model, and then transforming it again and again. Each time the team gains insight, the model is transformed to reveal that richer knowledge, and the code is refactored to reflect the deeper model and make its potential available to the application. Then, once in a awhile, this onion peeling leads to an opportunity to break through to a much deeper model, attended by a rush of profound design changes.
It’s this set of ideas that really has me intrigued about what the author has to say, and curious what the principles of DDD are really all about.
I’m looking forward to reading some more soon!