[sgmb id=3]
So, I have been in one of the tech talks and there I got to know about this methodology named domain driven development. It was first described by Eric Evans and from then the domain driven development philosophy came into picture.
So what really is this philosophy
The idea is to focus on the heart of the application, focusing on the complexity that is intrinsic to the business domain itself. We also distinguish the core domain ( unique to the business ) from the supporting sub-domains ( typically generic in nature, such as money or time ), and place appropriately more of our design efforts on the core. [ Taken from this article ]
The main focus of this philosophy
Ubiquitous language
Keeping a consistent language across your product will help you and other to understand and well and build around it. Lets take an example of Address, you may use street, locality, adress_line_2 anything for workaround. But should you really do this and confuse your developer, product guy, even consumers sometimes. So keep the language consistent and thus it will help it better understanding and every person will be on the same page.
Model
With model here we don’t mean the ER diagrams or the database model. Here we refer as the set of concepts that we chose to implement in our product, it can be represented in any software or code itself. Models are like saving a cost. There are many ways to save the cost. We can save it in simple int or double. But this may cost us problem in future so thinking about the model is very important. Lets say you used double for saving the cost and now your product is launched in countries with different currency thus leading to code change which is done at every place currency is present leading to bad code for future. A better implementation could be
A = cost(value, currency)
And small functions to add subtract etc.
Now you may say it is over engineering for a startup. Yes you are right it is an over engineering and that is why the world is all about trade-offs.
Context or Bounded Context
Every domain model stays in it areas totally in separation from other contexts. So now the constraint is that we cannot build relationship among the model we build as they remain in their context. Thus is it a bad model and how can we interact between models and it is very very important to make business logics.
Domain Driven development defines new set of rules between the bounded contexts. Thus the relationship is solved by these linking of BCs together.
Published Language
The interacting BCs agree on a common a language by which they can interact with each other. This language is known outside the domain for other domains to interact. Subdomains agree on language first to do so.
Open Host Service
Gives a protocol to use to interact. It is similar to providing apis and RESTFUL webservice.
Shared Kernel
Two BCs work on common library or kernal of code. The part of code that is fixed will not change thus can be used by other to interact. Such code comes in this section.
Customer/Supplier
BC uses the services of another and is a stakeholder (customer) of that other BC. As such it can influence the services provided by that BC and this may also induce changes.
Conformist
BC uses the service of another BC but cannot make changes in that because it is not stake holder. Its like Uber providing its apis which you can only use and cannot make them to change.
Anti-corruption layer
One BC uses the services of another and is not a stakeholder, but aims to minimize impact from changes in the BC, make some tweaks in the code or write a wrapper around it to.
This is a simple Introduction of Domain Driven Development. If you want to learn more dig deeper into the internet space. Many many things are not covered here try exploring them if you like this abstract.
