Book Study - Eric Evans' Domain Driven Design

Our local Design Pattern Study Group has finished reading Eric Evans "Domain Driven Design".

The book is quite special. It's not the one that can be summed up with one sentence. It's not the one that can have no summary at all. The essence of Evans' book can be given in few pages. In fact, we were planning to make such a summary before we found out that Evans has done it himself. Enjoy Domain Driven Design Pattern Summaries at www.domaindrivendesign.org.

I'll fire my quick summary anyways:
The book taps into a large pool of ideas accumulated in software development over last years. Unit Testing and TDD, Refactoring, Agility, pragmatic approach to documentation, challenges of team communication, fundamentals of software design such Declarative Design, Analysis Patterns to name a few. Still it remains technical. .


The idea of ubiquitous language is expressed strongly in the beginning and was hammered down throughout the book. Somewhere over second hundred of pages we have really gotten it.

Part II, "The Building Blocks" is very practical: it introduces Entries, Value Objects and Aggregates, Repositories, Factories and Services and then carefully discuss how they align with each other. The Evans' magic turns the ideas which I already "sort of know" to "aha!" moments when they really cement together.

Part IV, "Strategic Design" is more abstract and resonates less with everyday experience. Yet I immediately used Bounded Context and Context Maps: the ideas and vocabulary became a great aid in a reorganization of the development we were making at the time.

Part III, "Refactoring Toward Deeper Insight" is in the middle. Chapter 10, "Supple Design", is a gem. "Intention Revealing Interface" is an example of something that everyone agrees, yet everyone benefits from Evans' perfectly worded reiteration of the this old true.

The book is now on my shelf as #1 on Software Design. I can't help thinking what a great power it would be if the whole team read Domain Driven Design and buy into Evans' ideas.

Reading the book with a group is a separate story to share. Why is it so great?

Firstly, this book is a tough read. Oh, it is written beautifully and very entertaining! But the thoughts are deep, the concepts are complex, and so many different ideas are brought together that it is hard work to cut through pages. There are 555 pages, by the way. So it takes some discipline to cut them through, and I am not sure if I have any discipline left after all discipline at work and some disciplines at home :-) With a group, regular meetings and peer pressure definitely helps.

Secondly, we got waaaaays more out of the book when together. Some things resonate with my experience, others are not so much. With a room of software professionals with variety of experiences multiplies. We share stories, discuss questions, work on examples and help each other understand different perspectives that would be lost if read along.

Finally it is just more fun. It is pleasure to be with people who are passionate about software development to the extend they just can't go home after work: they need to hang around until 10 to keep on talking about software design.

Now we are selecting a next book. The definite leaders are
"Pattern-Oriented Software Architecture, Volume 1, A System of Patterns" by Frank Buschmann, and "Refactoring To Patterns" by Joshua Kerievsky. Whatever the democratic choice is going to be, I am game.

Are you interested to join? Toronto Design Patterns Study Group doesn't advertise itself and doesn't actively recruit new members. But if you are as passionate about software development as we are, by all means come in, you are very welcome. Drop a line to http://groups.yahoo.com/group/dpsig-toronto/

James Shore Messed Up with Math

James Shore messed up with math. Look at article "Quality With a Name":

Design quality = developer time / change

Translated to plain English: "Design quality is proportional to Developer time", or "the more time we spend to make a change, the higher is the design quality". James, you don't mean it, do you?

But forget the math. Read the article, it is a good read: mature, lived out thoughts on software design. I may disagree with some definitions, but he is dead right on fundamentals.

Mainly, James was looking something better then "Quality Without a Name". He nailed it down:

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance. This definition, and the conclusions it leads to, are the most important things I keep in mind when considering a design. I have some core design principles I follow, true. I also have some techniques that are useful for the languages I work with. But I'm willing to throw them away--even the so-called "universal truths"--if I think that they get in the way of reducing developer time.

Enjoy reading the article (and skip Measuring Design Quality, the math there is messed up).

SCRUM Master's Cheat Sheet

Check out www.mountaingoatsoftware.com/scrum/.

Excellent "by the book" description of SCRUM practices. Daily Scrum, Product and Sprint Backlog, roles of Product Owner, Team and Scrum Master, Sprint Planning and Review and so on - all well written, illustrated and concise. If you are a Certified SCRUM Master (CSM), this is a great reference to refresh your own mind or share with team mates and project community.

Some SCRUM related resources are also available for download.

Mike Cohn, the Mountain Goat Software founder, is known by his book, "Agile User Stories Applied"