DDD vs DDD
Domain-Driven Design vs Demo Driven Development, a case for the “Yes upfront design” approach
The most popular software development project management method is Scrum. It is centered around short development cycles, a.k.a. sprints. We start coding but in small increments. At the end of each sprint, a demo of the working software is shown to the product owner and stakeholders. The stakeholders give feedback, then we modify the application, and so on until we reach the point when we can deliver working software.
Many organizations misinterpret this method as a green light to “no upfront design” and a “get coding from day one” approach. They believe we do not need to design the structure of the code.
I call this misinterpretation of Agile principles “Demo Driven Development”. With this approach, the whole team is rushed towards a short-term goal and encouraged to cut corners in order to have a demo ready for the end of the sprint.
This may seem like a good idea, it gets people focused on a common goal. Some may say it gets them working harder during the sprint, as they have an achievable goal and deadline. It also means product stakeholders have a chance to give early feedback, and if the requirements have been misunderstood this can be rectified early on.
I think this method may work for small projects, for projects with a relatively simple domain, or where developers already understand the domain well, like online shopping.
However, I suggest that this approach to software development is inappropriate for medium to large projects and for projects with a complex domain.
Various studies, such as the Standish Chaos Report, show that more than half of software development projects are not successful.
As we can see, the larger the project, the more likely it is to fail. So if your project is anything but small, you have statistics working against you. In order to increase the chance of project success, instead of adopting these “get coding from day one” and “no upfront design” software development styles, consider using a Domain-Driven Design.
DDD is a software development approach coined by Eric Evans in his book Domain-Driven Design: Tackling Complexity in the Heart of Software, initially published in 2003. Since then it has been enriched by many contributions from an ever-growing DDD community of practitioners.
Before we examine how DDD would benefit your project let's look in detail at “Demo Driven Development” practice (as I call it), or rather examine its shortfalls.
But first, a funny slide (they told me to put one in every presentation):
French mathematician Emil Borel postulated The Infinite Monkey Theorem in 1913 which states that a monkey on a typewriter hitting keys at random for an infinite amount of time would produce the complete works of William Shakespeare.
No upfront design
Scrum prides itself in a “No upfront design” approach. The idea is that we bring an Epic or a few Stories from the Backlog into a sprint. We focus on building a small portion of the product at a time. At the end of the sprint, we showcase what we produced and the product owner and other stakeholders give us feedback and tell us what to change. By iterating from sprint to sprint, changing and adding more code to the product, eventually, we will end up with a complete solution! Hmm, this reminds me of something…
Maybe you guessed, it sounds like this: “If you have an infinite number of sprints and a team of monkeys you will end up with the desired software solution” 😃
Okay, we do use software developers instead of monkeys — so we do not need an infinite amount of time. However, this approach does add a significant amount of time to most projects. And for complex and large projects this will result in code that is known, in the DDD community, as “spaghetti code” or “a big ball of mud”. The Constant Refactoring approach can help, but how many product owners and stakeholders actually allow it?
Start coding ASAP
After more than 20 years working in IT, the “Start coding from day one”, to me, is the biggest mistake one can make in a Software Development project. According to Domain-Driven Design principles, the developer's understanding of the domain gets distilled into code. In practice, this means that if software developers misunderstand the domain and requirements they will start building the wrong software solution.
It’s true that as a project progresses, after many iterations and sprints, developers will eventually understand what is required from them. Unfortunately, by this stage, they have created a mass of code that is poorly structured and therefore hard to change and maintain. This is the point where developers say to stakeholders: “We should really scrap all the existing code and rebuild this from scratch.” At which point managers start to look for some “good developers” to hire 😃.
The problem is not in the quality of the developers but in the use of the wrong software development approach.
Domain-Driven Design
Luckily there is another way. You don’t need to perform the proverbial “Two years analysis phase” as is often presented as a pitfall of Waterfall Methodology, nor do you have to start coding without any design. Instead, you can adopt a Domain-Driven Design approach.
Domain-Driven Design (DDD) is an approach to software development: a set of techniques, principles and patterns used to aid in the development of complex systems. It is not another project management method, so you will have to define a custom, iterative, development process that suits your particular project.
The goal of practicing DDD is to handle complex scenarios with a systematic approach in such a way that domain experts (stakeholders, product users, etc.) and the development team (product owner, software architects, developers, etc.) can collaborate effectively with minimum friction. Typically, they gather around a whiteboard during a Domain Exploration Session and produce various types of diagrams by using a number of techniques provided by DDD. These techniques are beyond the scope of this blog and there are many resources on the internet to give you an overview, including my story: DDD — an elevator pitch
Domain-Driven Design and Agile
DDD can be used in conjunction with Agile, after all, they are two different things. Agile is a project management methodology, whereas DDD is a set of techniques and approaches to software development. The main point I am trying to make in this blog is: Do not focus on demoing fully working software at the end of each sprint. Instead, you can demo various DDD artifacts that are the product of Knowledge Crunching sessions. For example, you could demo a Domain Story Diagram, an Event Storming sheet, a diagram of Entities in a Domain Model, a Bounded Context Map… All these artifacts can be demoed and reviewed at Sprint Review meetings.
This means that you can still iterate, but not by re-developing code, rather you can iterate through diagrams by refining the Domain Model. Changing a few diagrams is far easier (and cheaper) than changing working software.
In addition, if you are prototyping in parallel with DDD modeling then you can demo various prototypes while stressing to stakeholders: “this is only a prototype.”
Prototype from day one
Instead of starting coding working software from day one, we should start coding prototypes. This can be done in parallel with modeling. Prototyping differs from coding in that we are aware that this is throw-away code. We do not waste time testing the code and don’t develop details, we are “just playing” to see “how something will work”, we are getting familiar with the technology, with the “plumbing”. For example, we could experiment with how to create a React Form and send submitted data into a Pulsar Topic using Akka Streams. We want to investigate the mechanics of this concept so that when we start building the real thing we already have knowledge of it and have an infrastructure ready. Or maybe we just want to investigate whether this concept is appropriate for our implementation, after all, we may decide that it is not adequate for our project and choose another technology stack.
Reviewing the BDD specification.
Another good artifact for sprint review is the Behavior Driven Development specification as this is something that stakeholders can understand. DDD plays well with BDD, especially if you use the Domain Storytelling technique and diagrams. You can read my blog to see how you can take the output of a Domain Story diagram and use it as a Spock Testing Framework test specification.
I hope that in this blog I have raised your interest in DDD and shown that “Yes upfront design” is a useful approach because iterating and changing diagrams is cheaper than iterating and changing working software.
P.S.
And to finish on a happy note…
An actual monkeys experiment
In 2002, lecturers and students from the University of Plymouth MediaLab Arts course used a £2,000 grant from the Arts Council to study the literary output of real monkeys. They left a computer keyboard in the enclosure of six Celebes crested macaques in Paignton Zoo in Devon, England for a month.
You can download the full text created by the monkeys from the Wikipedia page, see the “Actual monkeys” section. The text is titled NOTES TOWARDS THE COMPLETE WORKS OF SHAKESPEARE and includes pictures of the authors, monkeys. (No, they did not produce the complete works of Shakespeare, yet …😄)
