According to the "Implementing Domain-Driven Design" book (by Vaughn Vernon and foreword by Eric Evans - one of the precursors of DDD), the core of Domain Driven Design philosophy is not about technical stuff.
What do you mean??? That was the first thought that came to my mind when I read it. Let's dig a little bit more in this subject in order to figure out what the above information really means.
What do you mean??? That was the first thought that came to my mind when I read it. Let's dig a little bit more in this subject in order to figure out what the above information really means.
So... What DDD is about?
DDD is about understanding how your domain really works. Identifying the core, support and generic Subdomains will make it possible to build well designed models. A Domain, in a broad sense, is the business where you or your company are in. The emphasis of DDD is to identify Subdomains which together compose the whole Domain. Once you did it, you can develop your models inside of Bounded Contexts.
The benefits
Let's think about a business Domain of an e-commerce website (a pretty regular one). Without DDD approach, we might start thinking in a single Domain Model to support all the business requirements, which might include Product Catalog, Orders, Invoicing, Shipping, Inventory, etc.
If you have some hands on experience on modeling and programming a Domain Model for a system as described above, you know how can be difficult and extremely complex to define and keep a single class "Product" that support all those business requirements! Here is where the DDD philosophy shines: you don't need to go this way! Getting in the DDD philosophy, we should identify Subdomains inside the core Domain.
This way, Subdomains could be arranged so that each one of the business requirements mentioned above represents a Subdomain. For each identified Subdomain, you should set a Bounded Context. A Bounded Context, basically is a context where your classes, entities, etc. have a unique meaning and are in conform with a Ubiquitous Language.
Again, being very simplistic, a Ubiquitous Language means that there must not be divergence about any concept inside a Bounded Context. This way, it is possible and completely reasonable to have, for instance, different classes (with different meanings) using the same name but in different Bounded Contexts.
A class representing the abstraction of "Product" can exist inside the "Product Catalog" Bounded Context, meaning an item available for searching and selling and having its own pertinent attributes and methods. At the same time, another class "Product" can exist inside the "Shipping" Bounded Context, meaning what must be delivered and having its own specific attributes and methods too.
When you model thinking in a small and very specialized part of the problem, it is much easier to get a simpler, reliable and robust model!
If you have some hands on experience on modeling and programming a Domain Model for a system as described above, you know how can be difficult and extremely complex to define and keep a single class "Product" that support all those business requirements! Here is where the DDD philosophy shines: you don't need to go this way! Getting in the DDD philosophy, we should identify Subdomains inside the core Domain.
This way, Subdomains could be arranged so that each one of the business requirements mentioned above represents a Subdomain. For each identified Subdomain, you should set a Bounded Context. A Bounded Context, basically is a context where your classes, entities, etc. have a unique meaning and are in conform with a Ubiquitous Language.
Again, being very simplistic, a Ubiquitous Language means that there must not be divergence about any concept inside a Bounded Context. This way, it is possible and completely reasonable to have, for instance, different classes (with different meanings) using the same name but in different Bounded Contexts.
A class representing the abstraction of "Product" can exist inside the "Product Catalog" Bounded Context, meaning an item available for searching and selling and having its own pertinent attributes and methods. At the same time, another class "Product" can exist inside the "Shipping" Bounded Context, meaning what must be delivered and having its own specific attributes and methods too.
When you model thinking in a small and very specialized part of the problem, it is much easier to get a simpler, reliable and robust model!
The trade off
Of course, "there's no free lunch" and the trade off law is always present. Having "N" Subdomains, Bounded Contexts and consequently different models, adds complexity to the system as whole. In order to have a functional system able to support a real e-commerce operation, it would be necessary integrate your models and make all these parts working together.
For this, DDD offers a set of patterns and ways to treat and classify your Bounded Context relationships, like "Partnership", "Shared Kernel", "Customer-Supplier", "Conformist", "Anti-corruption Layer" and others. All of these are concepts regarding how you see your problem and how you organize it. Therefore, the fact is: it is going to demand more attention, time, complexity and work regarding integration between Bounded Contexts.
For this, DDD offers a set of patterns and ways to treat and classify your Bounded Context relationships, like "Partnership", "Shared Kernel", "Customer-Supplier", "Conformist", "Anti-corruption Layer" and others. All of these are concepts regarding how you see your problem and how you organize it. Therefore, the fact is: it is going to demand more attention, time, complexity and work regarding integration between Bounded Contexts.
DDD Concepts Misinterpretation
Unfortunately, there is still a lot of misinterpretation of these concepts. For example, I've seen people publishing tutorials on the internet referring to a layer used to decouple the application front-end layer from the application business layer as the "Shared Kernel". Well... according to the DDD concepts, a Bounded Context might even be an independent system. "Shared Kernel" is a technique to share Model Concepts (see Ubiquitous Language above) between Bounded Context, not between layers.
In the "Product" class example above, if it had the exact same meaning (same meaning, attributes, methods, etc.) for more than one Bounded Context, it could be treated as a "Shared Kernel". Domain Drive Design concepts and philosophy might be a little bit hard to understand at first. That has lead people to misinterpret some concepts and consequently causes mess.
In the "Product" class example above, if it had the exact same meaning (same meaning, attributes, methods, etc.) for more than one Bounded Context, it could be treated as a "Shared Kernel". Domain Drive Design concepts and philosophy might be a little bit hard to understand at first. That has lead people to misinterpret some concepts and consequently causes mess.
Conclusion
I hope I have been able to convey and explain the very basic and real meaning of "DDD Core philosophy". As explained, it is much more about how to approach your problem instead of technical stuff. I strongly recommend the reading of the book "Implementing Domain Driven Design", by Vaughn Vernon, for those who want to master the Domain Driven Design concepts.
Related posts:
Domain Driven Design: a "hands on" example (part 1 of 3)
Domain Driven Design: a "hands on" example (part 2 of 3)
