From our early days of coding we have always learnt duplication is BAD and it is so true. It decreases the quality of the code. Team’s have to remember all the places where similar functionalities exist and enhance/fix code at all the places. Since its a manual process to remember things at multiple places most of the newbies who are not well equipped with the code usually fixes the code in only few of the parts, breaking the system in some scenarios.
But in recent year with DDD getting popular we are hearing more often that duplication is not as evil as we thought and its necessary to have duplication in certain scenarios to have clean microservices and building an autonomous teams.
In my last article we extracted domain services from requirements and we got to a completely different set of services as shown below.
Now the service dealing with payments will have a customer entity that will have customer ID and payment options of the customer, while shipping service will have another customer entity that will have customer ID with shipping details of the customer. In DDD, such boundaries where duplicate entities can exists is termed as “Bounded Context” in DDD.
One of the key practices to follow in DDD is to agree upon a “Ubiquitous Language” where domain experts, developers and users mean exactly same thing when talking about a model. In our example the domain experts, developers and users when talking about customer within shipping context would primaraly mean the delivery or pickup address, delivery type etc.
In DDD the CONTEXT IS THE KING.
Read More »
Naveen's Weblog 