Domain Driven Design & Agile — They Work Together!

I recently found myself tweeting a full, 140 character message. But, after it gained the attention of a few people, I felt I needed much more room than a simple tweet to cover my thoughts. This article serves that purpose.

Context

Let me set the stage with a bit of context. Simon Brown, a software architecture advocate and author I follow and have read, tweeted this:

My maximum-length response was:

I have to be honest with you, as I always am: I found Domain Driven Design after many years (more than two decades!) of software development. This decades-long experience likely made understanding Domain Driven Design easier for me. I had plenty of past mistakes and failures to draw upon which helped put the lessons into focus.

Domain Driven Design Taught Us…

An understanding of what? Domain Driven Design set out the understanding that we must start with a fundamental and shared understanding of our domain, through a consistent, ubiquitous language. Without a fixed language shared across the entire organization, we will stumble to agree on anything. Actually, without a common (ubiquitous) language, we tend to bowl right through things with the less technical people around us nodding their heads and trusting that we know what we are doing. Our internal agreements of how the system will work will be as flimsy as our agreements on the vocabulary.

Secondly, Domain Driven Design teaches us that the only thing constant is change: Domain models do not remain fixed. As we learn more by working with our domain experts, our domain model should also deepen over time. Domain Driven Design does not expect up-front design with miraculous, once and only once implementation. It expects you to live in the real world — one in which everything is not perfectly understood all at once — it expects and even calls for continual evolution over time.

Both the call for ubiquitous language and the call for a domain model equate to one thing:

Don’t Rush In!

Developing and designing good, quality software requires that we stop rushing about (like the age-old hare) and be more purposeful in our actions (like the age-old tortoise).

But Architecture Is Waterfall, and I’m Agile!

I skipped adding a head-banging-on-wall-gif here only because I am over forty, and my children laugh at me when I try to use memes. But, I think this would be an appropriate place for this.

Following a good Domain Driven Design methodology and mindset does not violate the agile paradigm. I think people too often say “I’m Agile” because they use sprints. Let us actually go line-by line over the manifesto:

1. Individuals and interactions

Forming a ubiquitous language and establishing an agreed upon domain model is all about the individuals interacting. You can do neither of these two things without these two important components.

2. Working Software

Software can only be declared working when the domain expert and the consumer agree that it works for them. It is really hard to have Working Software when you fail to get everybody on the same page and to understand your domain.

3. Customer collaboration

In Domain Driven Design, the customer is called something different — domain expert. The domain expert is the person who understands the real world implications of your software, and Domain Driven Design is all about collaborating with this non-developer actor.

4. Responding to Change

The only thing constant is change. It is a cornerstone to the Domain Driven Design mentality. Your model is constantly growing and morphing as you understand the domain better. Your model responds to change.

Domain Driven Design == Agile

I will be so bold as to make this statement. Lest you think me a fool, let us check in on what the signers of the Agile manifesto think about Domain Driven Design:

“[Domain Driven Design] belongs on the shelf of every thoughtful software developer” — Kent Beck

Ward Cunningham has a git repository holding Wiki documentation on the Domain Driven Design patterns. I doubt he would take the time to be a part of this documentation if he thought it was non-Agile.

Martin Fowler was one of the people who convinced me to read Domain Driven Design in the first place! Well, his website did; not him personally. His website is filled with Domain Driven Design information, and he references it often.

I could go on to look up more names on the manifesto to see what they think about Domain Driven Design, but by now I think you see the point: Domain Driven Design goes hand-in-hand with Agile development. If you do not have this in your library, take it from someone who waited decades: Buy it. Read it. Let it help you…

Think Properly!