Learning DDD as a Team
Learning DDD as a Team
Read on about some of the roadblocks and best practices Coolblue experienced in their implementation of domain-driven design.
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
A few sprints ago my team and I decided to invest heavily in Domain-Driven Design. We already started to develop the new microservices in a DDD fashion, with our domain as the central component. However, we wanted to formalize it and move the old microservices to this new paradigm.
During this period we used several tools and techniques to aid us in figuring out what was the best approach for us. And we are Agile: probe, experiment and evaluate. If it doesn't work, learn from it and move on!
Activities as a Development Team
As a developer, one of the best tools is a pen and paper. As a development team, nothing is better than a whiteboard and markers. Before or during the development of a component, we gather the team around our whiteboard and we scatch potential solutions for the problems in hand. It helped the team to focus and reach a common understanding, making the software implementation easier.
Coffee & Lunch Breaks
We have around 150 software developers, so it's common to take a coffee or have lunch together. Most of the times, during our chats, it drifts to the problems that we are facing. It's a great informal platform to share our ideas, struggles, and solutions for the problems. As Kevin Boles once wrote: "Smart people learn from their mistakes. Wise peoples learn from other peoples' mistakes."
Here at Coolblue, we host private craftsmanship sessions. During the meetings, we have the opportunity to work on a particular problem, sharing our thoughts and discussing possible solutions. It's more formalized than the coffee & lunch breaks.
Event Storming Sessions
Another activity used by our team is Event Storming sessions. We use this activity to help us to match the new business requirements and all the technical debt that we need to catch. This is an opportunity to optimize the work to be carried out, minimizing the creative tension between the developers and the business. It also raises the business awareness for software risks, since our domain has goals to help the company grow; to achieve the goals, we need to minimize the risks or acknowledge them. Transparency is the keyword!
One of the challenges is to set the correct language, terms, and definitions. Although we are developing software, we are doing it to achieve a business goal, and given that, the software should be read like a book. Also, the software naming should match the business terms, making everyone lives easier. Please, raise your hand if you've never found variables names that don't match the business terms.
It's paramount for the development team to speak the same domain language; it will pay dividends in the future once, for instance, a refactor is needed, or even when the software goes into maintenance mode.
Any good resource in this space points to the bounded context as the central pattern for the DDD. When we are building software for a new domain, discovering the bounded context is the first challenge that a development team faces.
However, in my experience, in a growing company, the development team needs to be actively looking for changes in the bounded context, since the software should serve the business, not in the other way around. This is a massive challenge, which not only requires the ability to have useful metrics in place (especially business KPIs), but also to keep asking if the software continues to have the same positive effect within the user base.
Value to the Business
Close the Gap Between Development and Business
It's important to keep the development teams as close as possible to the business. Applying DDD techniques, it helps the development team to bring the domain concepts to the center of the software development, closing the gap between the development and the business.
Use of the Same Language
Once the developers start to use the same domain language as the business, it decreases the time in the discussions between the business and development, since it is not needed to translate technical terms to business terms.
Helps the Product Owner to Make Informed Decisions
All these activities end with valuable insights to the Product Owner. She or he can prioritize the work, based on the team's feedback and the business necessities. It also reduces the creative tension between the developers, trying to improve the speed of the features delivery.
Value to the Development Team
Software long-term sustainability is essential. In other words, creating and deliver software at a high pace, minimizing the technical debt. During my career, I found the DDD concepts and techniques more useful to increase the long-term sustainability of the software, since it uses the same domain language as the business. It helps the development teams to add new features to an existent component since it matches the business processes.
Vision and Goals
The activities carried by the development team help to state the vision and goals for the upcoming period. Although its impossible to create a roadmap six-months ahead, due to quick company growth, it empowers the team to help the business to achieve our (domain) goals.
Sometimes we (developers) make assumptions that turn out wrong. Even in an Agile environment, whereby the feedback cycle is the centerpiece, and we work in an iterative process, we prefer to get it right since the beginning. Since we start to focus on DDD, I observed, the team began to remove the ambiguity during the software development process, thus increasing the speed and quality of the deliveries.
Clear Dependencies & Visibility
We work in one of the biggest e-commerce companies in the Benelux area, and it's near impossible for a team to own all the software to cover a business process. During this time we started to improve our documentation, focusing on the boundaries of the software that my team is responsible. It created a clear image of the upstream and downstream dependencies. It helped in the discussions with our peers accountable for the upstream dependencies, whereby we presented documentation in the same (technical) language. Using these artifacts, we are able to discuss the importance of the upstream dependencies, since it raises visibility and awareness for the inter-dependencies between the teams (and software systems).
It also raises the visibility since we hanged in our glass walls the software diagrams of our system. As a learning opportunity, we choose to document our software using the C4 model from Simon Brown.
Published at DZone with permission of João Rosa , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.