TACTICAL PATTERNS | Domain Driven Design

The role of the tactical patterns in DDD is to manage complexity and ensure clarity of behavior within the domain model.

Knowing tactical design patterns within the DDD approach is as important as having a deep understanding of strategic design patterns. In this article, I explain everything you need to know about DDD's tactical modeling process.

In the previous article, I touched upon so-called strategic modeling and strategic design patterns within the DDD approach. I demonstrated how you could specify conceptual borders to solve specific tasks within the domain — bounded contexts.

To implement a specific bounded context, you need to rely on low-level tactical design patterns, which are used to solve specific engineering & development problems. 

These patterns are: 

Entity

Value Object

Domain Service

Domain Entity

Module

Aggregate

Factory

Repository

In this article, I am going to look into these patterns.

When the tactical design patterns are used correctly, you can use ubiquitous language in bounded context. 

The software design model that includes all the patterns needs to demonstrate how rich ubiquitous language is in a given context. 

If this or that DDD term can’t be described or expressed with the help of ubiquitous language, it shouldn't be used in the model. 

If the modeling is underway with use of tactical design patterns (without ubiquitous language), it means that so-called light DDD approach is used.

So, let’s have a look at several tactical design patterns in the order they are described in Vaughn Vernon’s “Implementing Domain-Driven Design.”

Conclusion

Here we have it. We have looked through all DDD patterns. All of them can be used to develop specific bounded contexts. To begin with, you can start by specifying entities and value objects. Then, you can break them into separate aggregates to adjust and coordinate all the data and maintain business rules within aggregate borders. After than, you need to follow through with creation of factories and aggregate repositories. To adjust all the data within the system, you can rely on events. They can be created in the unified system, not simply in bounded context. 

I could also talk a bit about application, its layers, tiers, architecture, etc.; however, I decided not to do it to make a shorter version of the article. I hope, it will help you understand DDD more!

Please, let me know what you think about DDD and its tactical design patterns in the comment's section below!