Guerrilla DDD

6 min readDec 29, 2018

A bit of context

On june 26th 2018, I was lucky to be invited by the DDD Paris team among a bunch of DDD stars like Mathias Verraes, Yves Reynhout and Eric Evans, the author of the Design Driven Design book himself. All the conferences were great and the discussion panel at the end is insightful around DDD and our job as a developer. I highly recommend to take time to go see them (videos here), it’s only 20 min and the french presentation like mine are subtitled in english !

In my presentation, I talked about “Guerrilla DDD”. This term came from a discussion in a Scrum retrospective of my team and was inspired by the UX field where designers confronted with the difficulty of not being able to work properly, began to talk about guerrilla or “how to hack the organization to do their job” (See this book).

Why Domain Driven Design ?

The term was coined by Eric Evans in his book of the same title.

To use the good definition from wikipedia, the goals are:

placing the project’s primary focus on the core domain and domain logic
basing complex designs on a model of the domain
initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

One of the best things of DDD is that it pushes developers (and the whole IT team) to improve how they work.

By immersing themselves inside the mindset, they will take time to really understand the domain (aka the business) they are working on. They will explicitly and clearly project (as modeling) the business domain inside the code, making it almost readable by the business people.

In fact, yes, for the developers who didn’t already have this mindset, this is the greatest strength of DDD. Until you discover the harsh reality of many software development contexts:

what we call the business people, aka the Business Analysts or the Product Owners, don’t really master the domain they were assigned to.

It’s very visible in legacy software contexts.

Many times, they have really no clue how the business rules are implemented in this messy code. When they reach the point of the dreaded “we will look at the documentation”, you know you will have a long and difficult journey. Of course, we talk about a “legacy” application so no BDD or DDD practices to help us to recreate the business knowledge.

In other cases, what they really master, it’s the projection of the business in the legacy application. They are what Alberto Brandolini calls the Dungeon Master, “the one whose expertise was built from the intricacies of the existing systems”.

The biggest problem with this situation is that the legacy projection rarely represent the real business domain.

At some point, the business domain aligns itself on a bad application what I would call functional debt which is way worse than technical debt.

Moreover it’s not really because the persons are not smart enough but because there are many psychological biases which push in this direction like the “Dunning Kruger effect” or mostly “what you see is all there is”.

Taking back control

I will give a real life example to better understand what is the problem, how to regain control and put back the real business domain into the product and code.

Our team was working on the redesign of an old application in an international investment bank. The domain is mainly the approval process of complex financing requests. The approval process needs the analysis and decisions of different users.

The first big feature was to create a task management system (think todo list) to help them to see what are the requests to work on or to follow up. This task management was mainly done to show that the team could bring value quickly to the users around the old application. We had to retrieve the requests and decisions in the old legacy database which was the main source of truth.

For this, there are two situations : either the user is invited nominatively either he is invited by his team. For the latter, we discovered something disturbing : some users were assigned to multiple teams .. up to 10 … making the tasks management system almost useless for these users.

At this point, most developers will accept the fact and implement this need without a blink :(

Of course, the business asked us to do so ! They will also keep adding workarounds and quirks to make the whole thing usable but, at the same time, increasing quickly the accidental complexity of the codebase.

At this point, DDD undergo its test of truth. To keep the promises of DDD, you will have to say No and push the organization to change.

First, do everything you can to see real users.

In our case, taking one hour to discuss with one of the user of the application, was a magical experience because he explained why many users were assigned to multiple teams.

In their daily activities, each teams are a group of users following a set of firms (or legal entities) mostly around a sector (like energy or automotive). At the beginning of life of the legacy application, a set of teams were created, each one associated to a specific sector.

However modifying teams was so difficult that each time a user needed to follow a new legal entity or the firms were redistributed between teams (for ex due to an internal reorg), it was chosen to add the user to another team. Maybe the codebase was already not flexible enough or the business didn’t want to invest in this capability.

Finally what should have been simple like in the figure below:

was in fact like this

What we had discovered is the notion of functional debt presented before.

In the development team, we strongly fought against this with the representatives of the business which were pushing to keep what was implemented in the legacy application, mainly because they were accustomed to it and they feared to make something new.

We had to explain many times functional debt was putting the project in danger with accidental complexity, potential bugs and usability problems.

Luckily the dev team was strong enough to align everybody on the necessity to design teams in the application tailored with how the business teams do their daily work.

Finally the design we have created is now close to this: simple and a better projection of the business into the code.

The guerrilla dev team finally win and had its happy ending story.

Conclusion

In some context, to really do DDD, you will have to fight the organization and the wrong projection of business done in the legacy application, you will have to enter in guerrilla.

For that, you will need to:

Learn to say no
Find the hidden Domain expert
Make everything to talk him
Define clear domain by yourselves if necessary
Hack the culture

You will also need to learn how to talk to domain experts and for this Cyrille Martraire has great talks about it:

Of course,

Make DDD, not war.

Thanks @kawabytes and @Maxime_gelle for the rereading !

Guerrilla DDD

A bit of context

Why Domain Driven Design ?

Taking back control

Conclusion

Written by yannick grenzinger