"... the key to expert performance in many fields is domain knowledge rather than intelligence." 
Don Reinertsen

Domain Driven Design is a software development methodology, intended to achieve a software system closely modelled on and aligned with real business processes.

Traditionally development tends to be a technically led process, where requirements are passed from the business to the development teams, and then the development teams go off and produce their best guesstimate at what the requirements said.

In a waterfall approach this leads to large requirements documents that are diligently collated, analysed, reviewed and approved. These documents are then given to development teams to turn into working software.

Agile approaches can also accept the requirements documents that waterfall tends to produce, but for them to actually progress forwards they must be broken to small tasks and stories which can then be queued ready for development.

Domain Driven Design to a large degree steps back from these two distinct ends of the spectrum, and looks at how the requirements are gathered in the first place - if you like, it bridges the gap between doing everything up front and everything at the last minute.

DDD understands that requirements are never 'done', but exist as a living document. More importantly, the living document in question is actually the software itself - all other documents are an artefact and reflection of the code.

As the software system develops and grows, deeper understanding of the problem grows too - DDD is all about the discovery of the solution through deeper understanding of the problem.

Where DDD really differs though is that it sees the software system as a reflection of the business process, an enabler rather than the driver. DDD is deeply concerned about the business processes, business terminology and practices. Technical concerns are largely secondary and a means to an end.

The Ubiquitous Language is at the centre of DDD - this is a shared and growing language. A negotiated language derived from the business terminology and enriched by the development teams. If a business person doesn't understand a term in the UL, then the chances are the UL needs an evolution. If a technical person doesn't understand a term in the UL then the chances are they need a conversation with a Domain Expert.

The Domain Experts are the second essential component of DDD - people who deeply understand the business domain, and the business itself. These people are integral to the development process. They may not be required "full time" like the traditional Product Owners of some Agile methodologies, but they must be accessible continually, and be prepared to invest time in the process. Domain Experts are not to be considered outsiders, but as the core of the DDD process - they are as much a part of the development team as any developer or tester.

DDD doesn't begin and end - it is a constant process of re-evaluation, refactoring, remodelling and redesign - every conversation should bring you to a closer understanding of the problem. At no point is DDD 'done' - it is always there; the Ubiquitous Language grows and develops, the Domain Models change as understanding changes, code is restructured and refactored to better represent that understanding.

Artefacts will come and go, but only one really matters - the code base. It is the only expression of the solution that is free of abstraction. While documents may try to explain or describe the system, only the code does so without losing information. This means that in DDD the code must remain of high quality, be clear and expressive, be free of technical abbreviations or jargon, and as far as possible should make at least some sense to a Domain Expert when explained to them.

Clever code doesn't work in DDD, nor do magical processes or "you don't need to know" components. Domain Experts shouldn't need to become developers to understand what the key parts of the software system is doing for them.  They also shouldn't need to think in terms of databases or batch jobs or other technical concerns.

DDD is the ultimate expression of Agile - it is about dealing with a constantly shifting and evolving set of requirements - because as anyone who has ever been involved with a software project knows - it is very rare for a requirement to remain intact from the beginning to the end of a project, and almost impossible for it to do so as the business grows and changes.

Through constant conversations, DDD will guide you to an ever more accurate software representation of your business process.

---

Posted 05-16-2011 3:15 AM by Jak Charlton