Dear Junior
For quite some time I have been thinking about the relationship between different agile practices. Even if there have been confused discussions about "test-driven development vs design-by-contract" or "scrum vs domain-driven design", I seldom (if ever) see them conflicting. But what are their relationship?
Especially I have been thinking a lot about the relationship between three practices I use in my daily work, and which I think work really well: Domain-Driven Design, Behaviour-Driven Development, and Scrum. These three practices does definitely not compete, rather they are part of the same eco-system. Still, it is not totally obviously how the work together.
For some time I elaborated with the idea of describing them as orthogonal, which made sense to me as they address different "dimensions" of development. However, I was never satisfied with that metaphor it as did not convey that these practices support and help each other, which is my experience.
What I have finally settled for is to describe them as a "stack" in the same meaning as the web-protocol stack "HTTP/TCP/IP". In the web-stack, each level provides a platform that the above-lying levels benefit of, and vice verse levels on top are supported and helped by the services from the levels at the bottom.
I find that the relationship between Scrum , BDD, and DDD very closely resembles that of a stack, and let me dive into each layer to explain why.
Scrum is a nice, lightweight project framework. It handles how to structure the work of getting development requirements/wishes - stories to use the terminology of Scrum - from stakeholder ideas through development work to finished software and doing so at a sustainable stress-level and pace. However, it (intentionally) says nothing about the format of the stories, and that question is actually out of scope. It does point out that the stories are not definite answers, but starting point for conversations between the team, the product owner and the stakeholders. But, the effectiveness of the process is definitely dependent on how well the format of the stories support those conversations.
What Behaviour-Driven Development (BDD) brings into the situation to me is to provide a very nice format for the stories. It starts with the "As I want so that ", and enhance it with clarifying examples on the form "Given , when , then ". I have found this format to be extremely productive when a discussion start going around in circles. And, it doesn't matter very much if it is a discussion within a development team or during a story-writing workshop with stakeholders. When I feel the discussion is on the slope of diminishing return, I break in and say "Let me see if I have understood this: can we phrase this as 'As ... I want ... so that ...', and either I am fairly on target and the discussion can move on, or I am off target and it becomes clear what needs to be resolved.
However, the extremely condensed format of BDD is very dependent on that the words we use are well understood, and that the risk of ambiguous interpretations are low. At least we need a shared understanding of the most central concepts, otherwise we run the risk of late-discovered misunderstandings.
Finally, what Domain-Driven Design brings is focusing on that shared understanding of the most central concepts. Here 'shared', 'understanding', and 'most central' play key roles. With 'shared' we mean that everybody involved relate to the same concepts, not only all developers and the DBAs, but also the GUI designers, the users, the product owner, those funding the work etc, this is the fundamental meaning of "ubiquitous language". With 'understanding' we mean something very precise - actually to precisely define the terms for the usage in this context, when communicating about this system. With 'most central' we acknowledge that this is heavy work, so we should only do that where it makes a different. This is what DDD refer to as the "core domain".
Of course DDD is furthermore supported by other practices, skills and disciplines like negotiation, linguistics and sociology, but I let my stack bottom-out here.
So, to turn it all around, and walk the stack bottom-up: Domain-Driven Design provides the stringency and preciseness that Behaviour-Driven Development needs to make the story-conversations productive that lets Scrum smoothly process visions to software.
I have found that Scrum on-top-of BDD on-top-of DDD, or rephrased Scrum/BDD/DDD is a development stack that works very fine for me.
Yours
Dan
ps A good domain model might be used to get a canonical model for the information. Improving stories further can be done by thinking about the as-a-clause as expressing stakeholder instead of actor or user. And, well understood stories are of cause crucial for release planning to work.
Some really fundamental sites:
ps A good domain model might be used to get a canonical model for the information. Improving stories further can be done by thinking about the as-a-clause as expressing stakeholder instead of actor or user. And, well understood stories are of cause crucial for release planning to work.
Some really fundamental sites: