Domain Driven Design

I recently bought Domain Driven Design by Eric Evans. See my initial review for some background. I have to say that this is the best software development book I have found in, well probably forever. I've barely started this 500 page monster and I'm already pumping my fist in the air in excitement ;o) Highlights so far: (headings, typos and spelling mistakes are mine)

1. How design fits into the Agile process

Preface p.xxiv

"In fact [Agile processes work] best for developers with a sharp design sense. The [Agile] process assumes that you can improve a design by refactoring, and that you will do this often and rapidly. But past design choices make refactoring either easier or harder. The [Agile] process attempts to increase team communication, but model and design choices clarify or confuse communication."

And that is one reason why I would take a handful of handpicked developers I trust over a huge (possibly outsourced) mass of development teams. It's not even about education - it's some mix of intuition, aesthetics, a desire to learn and committment without stubbornness. One of the top 3 developers I have ever worked with from around the world has no formal tertiary education at all.

This next quote is a gem that I think applies to many iterative processes as well as software design. Preface p.xxv

"Exploration is inherently open-ended, but it does not have to be random."

2. A bad model (or no model) will bite you in the bum

Page 4

"... Using a model in these ways can support the development of software with rich functionality that would otherwise take a massive investment of ad hoc development".

And there's the win. You just can't break through some ceilings of software complexity without a good model. Sometimes you can bludgeon your way through with a mass of ad hoc development. Other times your development team, number of lines of code, timeline and budget will scale beyond all reasonable proportions, such that no-one understands the problem any more, let alone the code, and you don't even have a language sufficiently powerful to discuss the problems.

I'll discuss the positive side of this equation in highlight (5) below.

3. Ingredients of Effective Modelling

Page 12

1. Binding the model & the implementation [early]
   ...
2. Cultivating a language based on the model
   ...
3. Developing a knowledge rich model
   ...
4. Distilling the model
   ...
5. Brainstorming & experimenting
   ...

YES YES YES! (pumps fist wildly in air) On reflection, every successful project I have been involved with has had all or nearly all of these points as strong elements of the design & implementation process. I have just never distilled them so clearly or heard anyone else succeed to that end. Fantastic!

4. The fundamental problem with the waterfall process

Page 14

"In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers ... This approach fails because it completely lacks feedback."

Evans again gets to the nub of the problem with the waterfall process - there's no feedback loop. Take a look at nature, there are feedback loops everywhere. Where there is no feedback, or the loop is too slow, there is brittleness and failure.

5. The problem with simplistic iterative process / Benefits of building a good model

There are problems with simple iterative approaches as well.

"Other projects use an iterative process, but they fail to build up knowledge because they don't abstract. Developers get the experts to describe a desired feature and then they go build it. They show the experts the result and ask what to do next. If the programmers practice refactoring, they can keep the software clean enough to continue extending it, but if programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be built that way, but the project will never arrive at a point where powerful new features unfold as corollaries to older features."

And that my friends, is when a designer/developer really earns his dough - when powerful & valuable features, that are easy to implement on the codebase, become obvious out of the very nature of the model itself - often to the astonishment of the domain experts & users, who say "why didn't I see that... I never even realised that that is what our process was doing".

Wrapup

I'd better stop quoting now before I start running into copyright and fair use issues! I'll come back to you when I've digested the suggested processes and give feedback on that. Normally I would be very suspicious of any purported 'procedural approach' to software modelling, but I am so impressed with what I have read so far that I'm happy to believe that Evans can come up with the goods.

In the mean time if software development and/or design is your thing, you *really* need to buy this book.

Domain Driven Design
Eric Evans
Addison-Wesley
ISBN 0-321-12521-5