I’ve read Domain-Driven Design (DDD) a couple of times now and consider it the most influential book on the way I develop software. But I’ve yet to blog about it. It’s time to change that.

Firstly, serious developers and analysts simply must read this book. It’s the sort of book I’d demand be read if I owned a software organization, though (being generous) around half of the book is applicable to Analysts.

Before I read DDD the concept of a Domain Model was somewhat fuzzy, even after reading Patterns of Enterprise Application Architecture. So often I’d seen ‘Domain Models’ purely holding state. I’d joined teams late in the game that had developed ‘intelligent’ Domain Models, but how they got there was a mystery. Questions like:

• Why had this domain concept become a class?
• Why apply this pattern in the domain layer?
• What direction are we headed with the domain model?

…the answers were never clear to me. Often one technician on the team had the answer, but I didn’t feel empowered with the knowledge to act without their consultation.

DDD hits home the importance of Domain Models and presents infinitely more information than development guidelines like ‘objects should have both state and behavior related to that state’. My most significant learning from it is an approach for distilling real world concepts into software, concepts that linger in the mind of domain experts but never crossed the divide. I won’t go into detail here, but the book presents the essence of distilling those concepts - unifying the language used across roles and, more generally, throughout the team.

It’s now a rare day when a team member’s ear won’t be ringing to the sound of me stressing the importance of modeling objects on domain principles, rather than abstract, somewhat related or technical ones. Analysts directly contribute to assembling simplified object models and are on the receiving end of questions like ‘does this concept have a name?’, ‘is there a general concept that encapsulates these things?’, ‘can we break this thing down, what do you think it’s composed of?’, ‘how would you identify each of these?’.

From a requirements perspective, it’s shifted my focus from understanding the requirements and acceptance criteria in isolation to understanding the core domain; the business of the users. According to the Kano Quality Model, customers are delighted when they discover new and useful features, stuff they wouldn’t expect to see. Immersion in the domain is key to having this capability.

From a development perspective, it’s given me techniques to aid modeling the domain in software. They focus on keeping the software simple and reducing translation time between the software and the domain. Again, I won’t spell out in detail what’s best covered by the book, but it is the kind of stuff you can start practicing immediately, the majority of it transcends languages and is bound to be relevant for many years.

The book also offers solid advice to leaders on effective team structures and subdividing teams and domains. This ground is probably less explored than other parts of the book but it’s no less important. From my experience it is used less, quite simply, because changes of that magnitude requires organizational clout that is difficult for a team to ascertain.

Here’s a brief list of observations from my DDD experiences:

• I find myself spending more time thinking, less time doing while at the same time being more productive
• I’m more proactive in engaging analysts. Emotionally there’s less of a divide between developers and analysts
• The code is more consistent and easier to navigate. You are less likely to be able identify the code of an individual
• You fear changes to the code less
• You strive to the understand the business’ problems more and focus less on simply producing software
• Design discussions are welcomed and flow naturally, there’s often less friction
• Breakthroughs, refactorings that significantly simply the implementation, come earlier rather than later

Credit where credit’s due; this book is quite simply an excellent geek read. For more info see Domain-Driven Design.

To manage should not imply authority. Authority should land on the role who practices the decisions most.

Managers should be accessed on the accuracy of their reports and their ability to encourage collaboration when necessary.

To managers:
Set a good example for the team. Trust in the skills of your colleagues. Encourage collaboration. Involve others in decision making. Make informed choices. Innovative IT shops don’t base decisions solely on what worked yesterday; they continually scan the market for new technologies and ideas. Why shouldn’t you?

When I purchased Organizational Patterns of Agile Software Development I had a couple of things I wanted to sponge:

• Understand more about the structures of organizations and how they can nicely evolve.
• Learn more about the world of software development as managers see it.
• Gain an appreciation for the origins of XP.

It delivered on all points.

For my first two goals it provided reams of useful information on organizational healing and growth, and about the principles and practices of highly successful teams. For those wanting to know more, the book bases its core (a series of pattern languages) strongly on empirical evidence gained from analyzing highly efficient and successful organizations. It focuses on the values of these organizations and the product of these values – their structure and communications. It stresses the importance of organizational learning, the key to allowing organizations to remedy their dysfunctions. It presents some strategies organizational introspection and learning. As with most books I read the theory all seems sound, but this book goes deeper proving to you it works in practice by presenting successful use of the patterns. Often the authors provide insights that transcend software development, but that often seems to be the case for organizational/management theory. They also present plenty of antropological references that substantiate their theories and patterns, demonstrating stong background knowledge (for example Maslow’s heirarchy of needs).

As I read through the patterns, shortcomings of organizations I’ve worked for became very obvious. The patterns made paths to healing these organizations very clear. To me thats a sure sign this book is good value. While I’m usually a developer lacking the organizational influence to implement these patterns the book stresses you can plant the seed and play your part with your immediate team and colleagues.

On the origins on XP, it did provide some teasers. It cites Ward Cunningham’s Episodes Pattern Language work as providing ‘much of the foundation material for XP’. An early reviewer of the first published version of the patterns ‘would later go on to be one of the founders of Extreme Programming’ (anyone know why no name was mentioned here?). An early publication of the book ‘was an early influence on SCRUM’, a process familiar to all the ThoughtWorkers out there. So it certainly points you in directions where you can get more information about XP’s inception.

For those of you who have been disturbed with my passion for software design patterns in recent years, expect it worsen as our pattern conversations will now surely touch software and organizational design patterns (i.e. code and politics).

For those of you who have a passion for being a technician and staying that way, rest assured the book is targeted for developers, not just managers. The authors acknowledge their developer audience saying, ‘we predict that many that read this book will not be managers, but developers’. They even present some software design patterns that strongly align with the organizational patterns (although I wouldn’t recommend them).

Keeping true to the critical nature of my blogs though, I do have a couple of gripes. I raised on eyebrow when reading the authors ‘chose “Agile” for the title out of marketing concerns’. The patterns promoting an architect role did little to counter my animosity towards the role. The software design patterns presented seemed largely out-of-place and were very questionable designs, almost shoved in to convince the reader that the authors have been developers.

They also had a dig at XP on a few occasions, points I could see some merit in but largely disagree with:
Quote: ‘….if the organization adopts a policy of daily status meetings, it perpetuates the crisis mode or even creates a crisis mode…’. They go on to explain, ‘Even when not at work, the people will have work on their minds so they can be prepared for the next day’s status meeting.’
Rebuttal: Status/stand-up meetings streamline communications, allowing the team to engage in short and sharp conversations. The team also gets a collective picture of status allowing them to immediately identify and resolve blockages. These benefits are valuable to any collaborative team effort, crisis or no crisis. Regarding work remaining on the mind, reporting status becomes part of your natural rhythm of activities. I haven’t found it adds more stress to report on progress, any conscientious developer should know where they are at without expending any additional brain processing cycles.
Quote: ‘Other aspects of XP – such as the inability to work alone and the need to always have your thought processes open to a pair programmer – help sustain crisis mentality.’
Rebuttal: I see pairing as offering more opportunity for the collective knowledge of the team to be expressed in the code and to learn from others. I do not see it as a negative activity, a subtle way of assessing the adequacy of my domain knowledge or programming. Granted the less experienced are usually more suspicious of its merits.
Quote: ‘…focus on organizational learning distinguishes organizational patterns from other organizations such as XP, which, though rooted in principles, imposes those principles…’.
Rebuttal: XP has feedback, learning and evolution at the heart of its principles. XP doesn’t ‘impose’ principles, you progressively take what works most effectively for your context and culture, much like organizational patterns. Also, much like organizational patterns, they have individual benefits - benefits that strengthen and expand in symphony with other practices.
(Perhaps my instinct to defend XP indicates some close-mindedness on my part)

Regardless of these criticisms, I recommend anyone whose sponge wants similar information to what I craved to make the mental investment.