DDD, like agile and software craftsmanship, is very hard to teach.
We can explain concepts, describe patterns and practices, show some good habits. Still we can’t easily teach them, they are too large. The cognitive load is too heavy.
The consequence is that we usually focus on a subset of practices, and claim this is the essence of the principle. This is why some people believe DDD is tactical patterns, software craftsmanship is TDD and agile is SCRUM. It also explains why frameworks or simple patterns like micro services are over used.
I find this dangerous and believe it’s important to understand what these hard topics have in common. If we understand what is intrinsically hard in them, we may learn how to teach them in a more efficient way.
It’s not about answers
It’s about questions. The three topics do not bring magic answers to our problem. They usually bring more questions. These questions allow us to evolve, to improve ourselves, and to dutifully accomplish our jobs.
They require being mature to accept that every answer we find will lead to more questions. They require courage and perseverance, but it’s worth it, because improving our habits will improve our professional life.
It’s not about a generic solution
It’s about context specific situations. There is a single answer to these three questions: What should we do to be craftsmen? What should we do to be agile? What should we do to be great DDD practitioners?
The answer: It depends.
What is our context? Do we work in a multinational or a startup? On a web or desktop application? In the finance or healthcare industry? The combination of all the specificities of our jobs is our context. For each context, different implementations are required.
What makes sense in one context is not necessary what makes sense in others. Every single architectural pattern coming out of Silicon Valley is not necessary a must have for your next project.
It’s not about technical stuff
It’s about people. The deep roots of DDD, software craftsmanship and agile are about people. Unfortunately, we mostly apply technical practices hoping to solve people problems, but fixing people is really hard.
Instead we should concentrate on understanding how they communicate and their particular business needs that are crucial to helping them create value.
Should we stop talking about it because it’s easily misinterpreted?
Of course not, but we should be aware of this problem when we are trying to communicate these subjects. I heard more great advice from Liz Keogh at DDD Europe 2016 that we could apply here: “Don’t strive only for the ‘whys’, put some ‘whos’ inside.” When speaking of practices, don’t forget about the team, about the context, and about why we think they make sense or not for us.
This is how we could be more effective transmitting passion on these subjects. By speaking about what it brings to us in our daily work, others may apply it, if they recognize a piece of their own context in ours.
It took me seven years to realize that I shouldn’t be an evangelist trying to push what I think are good practices. Instead I should have contextualized for others habits that improved my professional work.
Let’s be people centric
Let’s stop being technical monkeys always defending what we know as the only viable solution.
Let’s improve our communication about deep topics like DDD, software craftsmanship and agile.
Let’s be people centric.
Great Thanks to Brian Gibson for helping me to improve my English writing.