My colleagues and I have been making an in-depth examination of Eric Evans' intriguing, and deep, treatise on the
Domain-Driven Design approach over the last few weeks, as have
others recently. A lot of progress has been made in the last couple of years in trying to achieve the software development industry’s equivalent of a solo ascent of Mount Everest: models of software that can easily be turned into robustly designed working systems at the push of a button.
Since the release of his book last year, Evans has been getting an increasing amount of attention for his ideas, which represent what appears to be a surprisingly hard-headed, practical, and realistic view of the model-driven architecture vision. Evans may just be prescient enough and smart enough to be describing the next major vision of software development. Even more interesting, in our practice, as well as in the software development community, we are starting actually see projects seriously trying to implement forms of Domain-Driven Design.
Evans has an extensive background in delivering large systems and he understands the difficult problems involved with it. Most model-based development methods involve combinations of new tools and processes that don't fit well with the way that programmers actually work, or are too pure and don't address the messy realities involved in actual software development. Evans seems to understand all of this and more and paints a coherent, interlocking vision of how real model-driven development should work.
The Elements of Eric Evans’ Domain-Driven Design
Citing a hard-won set of largely old-but-new-again design guidelines, plus some fascinating new ones, Evans articulates a vision he calls domain-driven design, or DDD. It's worth reviewing these briefly because I am fascinated with the potential that Evans offers: software that meets requirements because there is one artifact everyone refers to, the model. In addition, Evans emphasizes uncompromising use of ubiquitous language of the domain, and a neat approach to maturing designs to be elegant and not-overengineered, which he calls supple design.
But describing this doesn’t convey the quiet self-assurance about these ideas that Evans consistently maintains throughout his story. On top of this, Evans is also acquainted with one of the key values of agile software development: delivering working software of high value to the customer. Awareness of this is present throughout his writing and it seems to add the edge of realism that is essential, in my mind, to making abstract techniques effective in the real world.
Domain-Driven Design is much more than just modeling however, it’s a carefully thought out set of techniques and approaches that this blog entry can’t hope to describe in detail. But I can say that they are a compelling and fascinating read. Like all genuinely new approaches, Evans ideas are sure to stir controversy, but their feeling of “rightness” is undeniable to anyone who has been in the software architecture trenches for any amount of time.
I encourage you to spend an hour or two study his ideas the next time you have a chance, you may very well be preparing yourself for the next major movement in enterprise architecture and software engineering.
Technorati: Enterprise Architecture, Computers and Internet, Programming