This evening I attended an inspiring meetup The pillars of Domain Driven Design with Marco Heimeshoff. I am quite new to DDD (Domain-driven Design), and Marco Heimeshoff did a great job explaining it.
In short, DDD is about translating business domain language into code, using one obiquitous language to create a bounded context in which to reason about the domain. This creates coherence and reduces risk and complexity. DDD can also create motivation, as it enables autonomy (through bounded context), mastery and purpose.
This talk has got me hooked and I am definitely going to learn more about DDD.
However, being an agile enthusiast, I couldn’t help but noticing the similarities between DDD and Agile. You could basically just swap the word DDD with Agile, and it would have made perfect sense.
From just this one talk, I gathered 10 examples where I felt that the topic could just as easily have been about Agile as DDD.
Example 1
What DDD/Agile is not:
- New
- Hard
- Overhead
- Only for complex domains
Example 2
It’s a dance, not a march (if someone gives you a three steps guide to DDD/Agile, it’s a hoax).
Example 3
DDD/Agile gives you the most benefit in the complex and complicated domain, but can also be valuable in the other Cynefin framework domains.
Example 4
Who should learn DDD/Agile? Everyone involved in the software development process.
Example 5
There is a bunch of methods (that consultants will try to sell you), but they are not the core of DDD/Agile. Only use them if they are useful to you in your context. If you find other more suitable methods, please use them instead.
Example 6
DDD/Agile changes everything in the company (like how we are organized, the way we work, roles). DDD/Agile is a mind turner.
Example 7
The more you try to prove that DDD/Agile works, the more it backfires because people will protect their identity (their existing roles).
Example 8
You are not a DDD/Agile person. You are a problem solving person, aiming to add business value.
Example 9
The first rule og DDD/Agile is: You do not talk about DDD/Agile.
If you use branded names, people will get too hung up on the methods and the practicalities, and lose sight of the underlying purpose (and expect it to come in a box with a certificate).
Example 10
The way to implement DDD/Agile is through small controlled experiments.
This is just the examples I had time to scribble down during that one talk. What other similarities can you find? What are the significant differences?
context is queen 
Thanks for writing this up! I particularly like example 8, and have seen unfortunate effects of failing to comply with “the first rule of agile” from example 9.
Would you mind expanding a bit on Example 7, about roles? I see how e.g. Scrum defines a new set of roles that do not fit with “the old way”, but how does this relate to DDD?
LikeLike
Thank you for the comment, Geir.
DDD does not define a new set of roles (neither does agile, but maybe there are methods under DDD that does). But there is a significant shift in responsibilities, especially in tech people.
Historically, we have seprated the business domain from technology. How we have bough IT-services through our contracts, budgeting, pricing models and waterfall projects have been enforcing this gap. Devs have been mostly concerned about implementing the written requirements and making technical choices.
In DDD there is a strong emphasize on exploring the busines domain before coding, and talking directly with business throughout the whole development process. Daily collaboration between business people and devs is also a principle of agile, and DDD explains why and how. This direct communication reduces the need for intermeediate roles and coordinators. It changes the leadership role, from telling people what to do to enabling autonomy, turning the hirarchy upside down. The traditional testleader becomes obsolete (though we still need testing skills). With bounded contexts we need fewer architects who doesn’t contribute inside the teams, because we get a less hierarchical structure where the teams take care of the integrations themselves.
More direct collaboration between different domains leads us from T-shaped to pi-shaped to comp-shaped skills, since we all need to understand more about different domains. There is this whole massive shift in roles and responsibilities, from indivitual responsibilities to enabeling cross-functional teams, and people will naturally resist if they sense that their existing role/identity is threatened.
I still don’t know enough about DDD to see the differences with agile, so this shift is the same i see in agile. And DDD enhances it.
LikeLike