Tactical and Strategic Domain-Driven Design

The Problem: Where Does Business Logic Belong?

Traditional layered architectures separate an application into controllers, services, and repositories. In this approach, business logic often ends up scattered across these layers. Services become responsible for orchestrating behavior, while data objects—often called entities or models in other contexts—remain passive containers with little to no behavior of their own.

Domain-Driven Design (DDD) offers an alternative. Instead of allowing business logic to spread across multiple layers, DDD concentrates that logic within a dedicated domain layer. The core idea is that the most important rules of the system should live in one place, expressed explicitly in code.

However, adopting DDD as a principle raises a practical question: how does one implement it? The answer requires understanding two distinct but complementary perspectives: tactical DDD and strategic DDD.

Tactical DDD: Structuring Code Within the Domain

Tactical DDD concerns itself with how to structure code inside the domain layer. It provides a set of patterns that allow developers to model business concepts directly in code, ensuring that behavior resides alongside the data it operates on.

What Tactical DDD Addresses

In conventional layered systems, several recurring problems emerge:

1. Business logic becomes distributed across multiple service classes.
2. Data objects remain anemic, containing fields and getters but no meaningful behavior.
3. Rules and constraints are duplicated across different parts of the codebase.
4. No single component has clear ownership over a given business rule.

Tactical DDD resolves these issues by assigning responsibility to domain objects. Instead of services orchestrating all behavior, domain objects themselves enforce rules and express business logic.

Core Building Blocks

Tactical DDD introduces seven primary patterns, each serving a distinct role in modeling the domain.

Entities

Entities are objects defined by a continuous identity rather than by their attributes. An entity changes over time but remains recognizable. For example, an order in an e-commerce system is an entity: even if its items or shipping address change, it remains the same order. Entities contain both data and behavior. They are responsible for protecting their own invariants—the rules that must always remain true. In code, an entity is typically represented with a unique identifier, such as a UUID or a business key, that remains constant throughout its lifecycle.

Value Objects

Value objects are defined solely by their attributes and have no identity of their own. A monetary amount, a date range, or an address are typical examples. Two value objects with the same attributes are considered identical. Value objects are immutable: any operation that appears to modify them instead returns a new instance. This immutability makes them predictable, safe to share, and free from side effects. Value objects are often used to describe characteristics of entities in a semantically meaningful way.

Aggregates

Aggregates are clusters of domain objects grouped together to ensure consistency. An aggregate defines a boundary within which all changes must remain logically consistent. For instance, an order aggregate might contain order items, status information, and total calculations. External code cannot directly modify the internal components of an aggregate. Instead, it invokes methods on the aggregate root—the designated entry point—which then determines whether and how changes occur. This pattern protects data integrity by controlling all access to the objects inside the aggregate. When persisting changes, the aggregate serves as the atomic unit of consistency.

Domain Services

While entities and value objects typically contain the core behavior of a domain, some business logic does not belong naturally to any single entity or value object. Such logic often involves operations that coordinate multiple aggregates or perform calculations that stand apart. Domain services fill this gap. They are stateless operations that express significant business logic that cannot be placed elsewhere. For example, a TransferService that moves funds between two bank accounts might coordinate two account aggregates, applying business rules that neither account individually owns. Domain services are distinguished from application services in that they contain domain-specific logic rather than merely orchestrating technical concerns.

Domain Events

Domain events capture something meaningful that has occurred within the domain. They represent facts that other parts of the system may need to react to. For example, when an order is placed, an OrderPlaced event might be raised, containing relevant details such as the order identifier, the customer, and the timestamp. Domain events enable loose coupling between different parts of a system by allowing components to react to changes without direct dependencies. They are typically immutable records of past occurrences. In a tactical implementation, aggregates often raise domain events as part of their state changes, and these events are then dispatched for handling elsewhere in the system.

Repositories

Repositories provide an abstraction for retrieving and persisting aggregates. A repository hides the underlying storage mechanism—whether a relational database, a document store, or an in-memory collection. The interface of a repository reflects the needs of the domain, using method names that align with business concepts rather than technical implementation details. A repository typically offers methods such as findById, save, and sometimes query methods that express domain-relevant searches. By using repositories, the domain layer remains unaware of persistence infrastructure, keeping the focus on business logic.

Factories

When the creation of an entity or aggregate is complex—requiring validation, multiple steps, or conditional logic—a factory encapsulates that complexity. Factories separate the responsibility of object creation from the object itself. They ensure that instances are created in a valid state, adhering to all invariants. Factories can be implemented as standalone classes, static methods, or dedicated factory services. The key is that the creation logic resides in a single, focused location rather than being scattered across the codebase.

Together, these seven patterns form the tactical toolkit of Domain-Driven Design. Not every pattern is required in every context, but each serves a specific purpose in ensuring that the domain layer remains expressive, encapsulated, and aligned with business realities.

Strategic DDD: Defining System Boundaries

While tactical DDD focuses on code structure within a single domain model, strategic DDD addresses a higher-level concern: how to divide a large system into meaningful, decoupled parts.

Why Boundaries Matter

Consider a large e-commerce platform that handles orders, payments, inventory, shipping, and user accounts. If all these concerns are modeled within a single, unified domain model, complexity grows rapidly. A change to one area may ripple unpredictably into others. Multiple development teams working on the same model often find themselves in conflict.

Strategic DDD resolves this by acknowledging that not everything belongs together. Instead of forcing a single model to cover all concerns, it advocates for clearly defined boundaries.

Bounded Contexts

The central concept of strategic DDD is the bounded context. A bounded context is a explicit boundary within which a particular domain model is defined and consistent. Inside the boundary, terms have specific meanings. Outside, those same terms may mean something different.

For example, the term customer in a billing context might refer to an entity with payment history and outstanding invoices. In a support context, customer might refer to an entity with open tickets and satisfaction ratings. Rather than forcing these two interpretations into a single model, strategic DDD places them in separate bounded contexts, each with its own model and its own ubiquitous language.

Context Mapping

Once bounded contexts are defined, strategic DDD provides tools for understanding how those contexts interact. These relationships, known as context maps, describe the nature of integration between contexts. One context may depend on another. One may translate data from another. One may act as a protective layer, insulating itself from changes elsewhere. Making these relationships explicit allows teams to manage complexity and coordinate integration intentionally rather than accidentally.

Ubiquitous Language at Scale

A ubiquitous language is a shared vocabulary used by developers and domain experts to ensure precise communication. Strategic DDD extends this idea by recognizing that a single language may not suffice for an entire enterprise. Instead, each bounded context can maintain its own ubiquitous language, tailored to the specific domain it represents.

Purpose of Strategic DDD

The goal of strategic DDD is to organize a system so that each part reflects a distinct area of the business. Boundaries are made explicit. Teams can work independently within their bounded contexts. Integration points are carefully defined rather than emerging as accidental dependencies.

Why Both Perspectives Are Necessary

Tactical DDD and strategic DDD address different concerns, and relying on only one creates significant gaps.

Focusing exclusively on tactical DDD may result in well-structured domain models with rich behavior. However, without strategic boundaries, these models can become entangled. The system may lack clear organization, making it difficult to scale across teams or to understand where one part of the domain ends and another begins.

Focusing exclusively on strategic DDD may result in well-defined bounded contexts with clear boundaries. However, without tactical patterns, the code inside each context may remain anemic. Business logic may still reside in services, rules may be duplicated, and domain objects may lack the behavior that makes the domain explicit.

Tactical DDD without strategic DDD is analogous to crafting well-written sentences without a coherent chapter structure. Strategic DDD without tactical DDD is analogous to designing a book outline but never writing meaningful content. Both are necessary for a complete implementation.

Integrating Tactical and Strategic DDD

In practice, strategic and tactical DDD are applied in a complementary sequence.

Strategic thinking comes first. The system is examined from a high level to identify distinct domains, responsibilities, and natural boundaries. Bounded contexts are defined, and decisions are made about where each concept belongs.

Once boundaries are established, tactical patterns are applied within each context. Entities, value objects, aggregates, and repositories are defined to model the behavior of that specific domain area precisely.

This separation of concerns allows each bounded context to adopt the tactical patterns that best suit its needs, while maintaining clean boundaries between contexts.

Key Takeaways for New Practitioners

For those new to Domain-Driven Design, several points are worth emphasizing.

First, DDD is not a framework or a library. It is a set of principles and patterns that guide how software is structured and how boundaries are drawn.

Second, tactical and strategic DDD address fundamentally different levels of design. Tactical patterns concern the internal structure of a domain model. Strategic patterns concern the boundaries between different models.

Third, both levels are necessary. Adopting tactical patterns without strategic boundaries leads to technical sophistication without architectural clarity. Adopting strategic boundaries without tactical patterns leads to clean separation without meaningful behavior inside the separations.

Fourth, the two levels work together naturally. Strategic boundaries define the containers; tactical patterns define the contents.

Conclusion

Domain-Driven Design provides a coherent approach to structuring software around business realities. Tactical DDD supplies the patterns—entities, value objects, aggregates, and repositories—that allow code to express domain behavior directly and precisely. Strategic DDD supplies the principles—bounded contexts and context mapping—that allow large systems to remain manageable and decoupled.

When both perspectives are applied together, the result is a system in which code reflects the business it serves, boundaries are explicit, and complexity is contained. For teams building software in complex domains, understanding and applying both tactical and strategic DDD is essential to moving beyond scattered logic and toward software that models reality with clarity and precision.