Domain driven design — eCommerce
In the previous article i have explained what is DDD and why we need to use it DDD.
In this article i will explain how to apply DDD strategic Design for eCommerce domain.
Basically, a Domain is the business itself. It is what your company does and, consequently, it is the “problem” you want to solve. As we have to build an e-Commerce System, our Domain is the e-Commerce business.
A Domain has its own strategic challenges which can be seen as Subdomains.
In other words, a Domain can be split in several Subdomains (a small specific view of part of the problem).
Each of them can be classified as Core, Support and Generic. Once you have split your Domain in Subdomains, it is a good practice and actually desired that you set a Bounded Context for each Subdomain.
“A set of specific software models, a specific solution expressing its own ubiquitous language.
It is a desirable goal to align Subdomains one-to-one with Bounded Contexts.
Does not necessarily encompass only the domain model. It often marks of a system, an application and / or a business service.”
DDD is an iterative process. This typically includes domain experts, developers, and other stakeholders.
This way, my sense tells me that a good solution for the problem, applying these DDD concepts, would be:
As it is possible to observe, I took strategic business challenges which are pertinent to the Domain and figured out some Subdomains. For each of them, I set a Bounded Context and classified it accordingly (Core, Support or Generic).
Core subdomains, that represents the main part of the Domain. In this case, I think that the “Product Catalog” Subdomain is the Core because it is what customers will be interacting and, therefore, is from where the revenue will come (customer shopping). Others Subdomains were classified as Support and Generic.
Support Subdomains are like auxiliary ones. In practice, you set a Bounded Context to it and create a specific application. It will work as a support application for the Core Domain application, however, support applications will have its own model.
Generic Subdomains are like support ones, but they have a strong particularity: they are so generic solutions that they could be used not only in the Domain it was created, but they could be used by others Domains too. It is completely reasonably that your “Access Control Application”, when well designed, can be reused to support other Domains which not the e-Commerce, for instance. That is why they are called Generic.
It is not difficult to realize that I have just organized my ideas about how I intend to approach the problem, and I have used DDD concepts in order to accomplish that. So, I ended up realizing that I would get a bunch of applications to develop. Perhaps, for some of these applications (like the Inventory one), an off-the-shelf software application would fit well. Also, it is perceptible that and integration between all these applications would be necessary.
If you imagine a real life scenario in a big e-Commerce company, it is possible that more than one team is allocated to support this operation. Possibly one team per Bounded Context.
DDD offers a way to classify and treat relationships between Bounded Contexts (Context Map). If you have heard terms like “Partnership”, “Shared Kernel”, “Customer-Supplier”, “Conformist”, “Anti-corruption Layer”, “Open Host Service”, “Published Language”, “Separate Ways” and “Big Ball of Mud”.
