What if we don’t find DDD patterns among the codes, like Aggregate, entities or value objects?

One the topics that have been noticed by some technical teams recently is designing and developing software systems based on Domain-Driven design approach. Although, the philosophy of DDD was raised many years ago by Eric Evans in his book Domain‐Driven Design: Tackling Complexity in the Heart of Software, but there have been always arguments within technical teams about the proper usage of DDD ever since. In this article I’m aiming to have a deeper insight through one of those arguments. Let’s start by the question that: is it possible to review project codes to determine whether it is based on DDD or not? What if we don’t find DDD patterns among the codes, like Aggregate, entities or value objects?

Let’s try to review the point of view from which DDD expresses it’s most important concern which is Linguistic expressiveness in designing business models. In fact the most important tool that DDD uses to design a business is “domain model” which in fact is an abstraction fully intertwined with ubiquitous language (UL). In other words, design process in DDD means nothing more than building domain models fully based on the UL with business experts and IT mans together iteratively.

During design phase in most of nontrivial domain models we face variety of languages. In fact these varieties lead to emergence of complexities in our modeling phase that need to be tackled efficiently, otherwise it can cause design to get into an unmanageable state. As soon as these linguistic diversities are recognized, DDD recommends to define explicit boundaries around the same-language models to approach such complexities. DDD names these linguistic boundaries as bounded context (BC) and it means nothing more than an explicit boundary around the meaning of a model. In this very decisive moment we can say that by defining these linguistic boundaries we are resolving the most DDD concern which is about linguistic expressiveness. So, Maybe now it’s not hard to answer the question mentioned at the beginning about how to determine whether we are doing DDD or not.

Up to here we still have not probed the situations where DDD popular patterns are absent from codes. As DDD is a holistic approach to the design of systems, it contains collection of patterns for the design of the models within a bounded context that is called Internal Building Blocks. These patterns include for example, the Value Object, the Entity, the Aggregate. As far as these patterns should help to develop models with as expressive as possible, so it is important to note that those patterns are not the only valid solution and there is no any compulsive application of patterns in DDD philosophy. So, existence of DDD internal building blocks in codes is not a good factor whether we are doing DDD or not.

At the end, let’s say again that DDD is less about patterns and mechanical wirings and is more about problem solving through close collaboration and communication.