Strategic DDD vs. Tactical DDD

• Modularity
• Craftsmanship

Definitions

Domain-Driven Design (DDD) is a vast field of knowledge, generally divided into two main areas. The terms come from the military:

• Strategic DDD, the “what”: This begins with mapping the territory, that is, identifying the contexts of the information system (more on that in a moment). Next comes the strategic decision to develop a particular context because it’s central to the business, and to use a product or service from the market for another context that isn’t. To illustrate, let’s say it’s Napoleon deciding to invade Russia—but I wish you more success than he had.

• Tactical DDD, the “how”: this is where we find all the expertise specific to modeling using entities, aggregates, value objects, repositories, and services—and, by extension, the hexagonal architecture. You want a domain that does neither too much (an obese model) nor too little (an anemic domain). Its responsibility is to implement the business invariants, without encroaching on the responsibility of the use cases, which ensure application coordination.

Reminder on modularity: bounded contexts

A quick reminder so no one gets left on the sidelines: it would take a little more time to give you a feel for what a bounded context is, but as a first approximation, we can say that a context is a functional module. In fact, we’re really talking about “modularization.”

Breaking down an information system into contexts thus minimizes interactions between them, without eliminating them entirely: contexts must communicate—to some extent. In other words, any other breakdown would result in more interactions, and we don’t like that because it ends up looking like a spaghetti mess 🍝

To be specific, a context represents an action. “Customer” will never be a context, because I can do a thousand things with a customer: sell them a refrigerator, ship them said refrigerator, bill the customer, or even provide after-sales service because they’re not sure if the light turns off properly when they close the fridge door. Four actions corresponding to four very different contexts.

But let’s get back to our discussion.

Strategy before tactics

Most of the resources available online cover tactical topics. Unfortunately, approaching DDD from this angle means looking at things through a very narrow lens.

In fact, engaging in strategic thinking without going into all the details of implementation isn’t a big deal. If here or there you don’t have the “right” hexagonal architecture, there will always be time to address it later. It’s actually the very role of strategy to establish priorities and a timeline. If the boundaries of the contexts are already clear in our minds, that’s a big step forward.

On the other hand, tactics without strategy are unlikely to work, by definition. Proceeding this way would be like saying, “We don’t know where we’re going, but we’re going there.” It’s like installing windows in a house whose foundation hasn’t been completed. You get the point. Building beautiful hexagonal architectures, setting up event-driven communication—all of that will have to be torn down if it turns out that the contexts are poorly defined.

The good news is that strategic DDD doesn’t cost much. It involves interviews, on-paper analysis, “potato diagrams,” and one or two weeks of intense reflection. OK, sometimes a little guidance is needed because there are a few habits to develop, but it helps quickly clarify the vision for the target audience.

Next, we refactor bit by bit. And with the right approach (Strangler Fig, Mikado, Golden Master), it can be done smoothly.

You can never start this work early enough: even if you’re only developing the first use case for your product, it’s good to know that a certain feature immediately leads to another use case.

This will prevent a lot of technical debt 😊