Another look on tech

My thoughts on tech.

Learning DDD as a team

10 December 2017

A few sprints ago my team and I decided to invest heavily in Domain Driven Desing. 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 to figure 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

Whiteboard sessions

As a developer, one of the best tools is a pen and paper. As a development team, nothing 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, 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 people mistakes”.

Craftsmanship sessions

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 discuss possible solutions. It’s more formalized than the coffee & lunch breaks.

EventStorming 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, 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 grown; to achieve the goals, we need to minimize the risks or acknowledge them. Transparency is the keyword!

Lessons Learned

Language definition

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 the hand, who 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 the 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, 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/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

Long-term sustainability

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.

Removes ambiguity

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.