The "honeymoon" phase in any project is the best. We've all been there, whether from the technical or business side. The dev team faces no obstacles, the backlog is minimal, and business is happy delivering to their customers.

Fast forward a few years, and the project has grown to include hundreds of features, thousands of active users, and increasingly complex questions. Your tech lead is discussing the significant changes needed for what seems like a "simple" new feature, and your business is asking questions your software was never designed to answer.

I understand that everyone's experiences shape their perspectives, and Domain-Driven Design (DDD) certainly has numerous benefits. However, in my opinion, DDD excels in understanding the business, specifically in answering the "why" behind requirements.

What is the Why?

Imagine receiving the following feature request from the business:

I would like users to be able to update their names.

This seems straightforward—a PATCH​ endpoint that takes the name, perhaps two story points.

PATCH /api/user/{id}
{
    "Name": String
}

This is a data-driven approach. You know what the user did, but not why. Imagine your software serves the country of Thailand or the state of California, both of which have relatively high rates of name changes. With the previous approach, you wouldn't know if residents change their names due to superstition, personal reinvention, correction of spelling, or simply getting married. To your system, all these scenarios are just one endpoint.

Domain-Driven Design aims to understand the flow and starts from software design. The above request from business should be challenged with your architect until you obtain a refined requirement.

Marriage licenses could include a request from one of the parties to adopt the last name of the other. The city hall wants to make that change on behalf of the resident.

Your architect might end up with the following event from the city hall.

event MarriageLicenseIssued {
    "FirstParty": {
        "Id": "String",
        "AdoptPartnerSurname": "Boolean"
    },
    "SecondParty": {
        "Id": "String",
        "AdoptPartnerSurname": "Boolean"
    }
}

Your system now has to listen to that event and react in a way that would eventually update a user's name.

Granted:

• This took more time in the design phase
• It only implemented a very specific use case. You can notice that if someone wants to change their name just for the sake of it, they currently cannot do that in your system since you do not have that generic endpoint.

But also, we achieved a functional integration that is super easy and straightforward to maintain. You can revisit this integration after 10 years and not need to refer to documentation.

Compression in Software Design

As you saw in the first example, with the data-driven approach, your business will eventually know that something changed, but not why. In the second case, however, the "why" comes hand in hand with any change.

This is an extremely powerful approach because it bridges the gap between technical implementation and business strategy. By ensuring that domain experts and developers speak the same language, the entire team gains a deeper understanding of the problem space. This results into more accurate requirements gathering, reduces miscommunication, and leads to software that truly reflects the business's needs and goals.

Finally

DDD is not the fastest, and it is not meant to be. I started this blog post to hopefully intrigue you to get to learn more about it.

If you can not wait for the next post, I would suggest

DDD Europe on Youtube

The Blue Book of DDD