TECH | Three DDD stories

In this article, I will tell you 3 real-life examples where Domain-driven design practices could have helped teams avoid lots of confusions and waste of time and money.

These stories feature:

1. Taking words into account

πŸ‘” The business guy comes to πŸ’» the developers to implement yet another great feature described with those words:

We want to implement the user account, so people can sign-in to our website, login or logout. When logged-in they will be able to see all their past orders.

This feature sounds cristal clear to you, after all, user accounts like that have been implemented since decades.

Later that day, πŸ’» the developers starts spiking some code when πŸ‘” the business guy comes back in their office:

Hi! Everything is going fine with the customer account?

🀦 …

Maybe, like πŸ’» the developers in the story, you are now feeling uncomfortable. What did the guy in a suit just say ? Did he say customer or user?

The developers already created a git repository called user-account, but this is not the more problematic: a simple confusion like this can give every participant of the discussion lots of trouble.

You might think, it is just a word, customer account or user account, it is the same thing right?

In fact, what the business guy was implicitly thinking: the users can only create an account after their first purchase, meaning that they are now customers. By mixing just one word with another, the team created a knowledge gap.

Building a Ubiquitous Language between members of your team is key to tackling complexity. Expect more than few sentences from your domain experts: communicate often and reveal the implicit.

2. Poke around with the core concepts

πŸ‘” The business guy comes back to πŸ’» the developers to implement yet another great feature described with those words:

We want our customers to be able to poke other customers, this feature is super urgent, I want our app to be the top poking app on the web!

Wow, this is exciting! There are too few poking apps on the web, and thinking that your company is going to be a major competitor in this new domain gives everyone goose bumps.

This time around, πŸ’» the developers are super serious about communicating with πŸ‘” the business guy. They iterate quickly, meet this domain expert every day. The Tech Department invests a lot of new instances of servers to be able to handle the poking charge. Interns are hired, satisfaction rate is high in the team.

After three months of intense programming, documentation writing and deprioritization: you finally have it: God! Customers are going to poke hard!

The month after, the head of finance comes to πŸ’» the developers and ask them to explain why they invested so much time and money for a feature with zero benefit.

🀦 …

The truth is that, this poking app was far from being your company’s core domain, you could have bought a monthly licence to the javascript library poke.js instead and save the company tons of money.

Determine what is important for the company (core domain) and what is not. Follow the Make-or-Buy Decision. Plus, keep a good relationship with the finance and accounting teams, they know more about your core domain that you think, or at least they know what actually brings money or not in the company.

3. Divide et impera

πŸ‘” The business guy comes to πŸ’» the developers with great news:

We are going to split you in multiple feature teams! We heard that it helped Spotify boost their productivity. Divide and conquer, bitch!

The teams have been decided by πŸ‘” the business guy and the CTO during lunch time:

The company being innovative, two thirds of πŸ’» the developers will join the API feature team, the rest will be dispatched between the supply and customer teams.

Very soon, half of πŸ’» the developers will leave the company.

🀦 …

The problem is that, companies are rarely driven by features or technology:

Take the time to explore the different sub-domains and contexts that your company tries to solve. Use strategical patterns and build a context map to discover the most efficient way to split your teams. This should not be done lightly.


I hope you liked those three domain-driven design stories, if you have other examples where you think domain-driven design could have helped you or your company, please share them!