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?