Using #bounded #context for breaking #database #model into #microservices using #domaindrivendesign

welcome friends in today's video we'll learn about the bonded context so after understanding bonded context you will be to easily divide a application into domains and sub domains and then create microservices for each domain or subdomain it is a very important concept whenever we decide to migrate a monolithic application into a set of microservices we have already learned about the strangler pattern which says that we should pursue this migration in a phase-wise approach we should migrate services phase by phase into separate micro services a detailed link for the strangle pattern is given on the top of the screen you may watch it if interested another logical point here is from where to draw the sword how to cut the functionalities of a monolithic application into separate functionalities so that we can create separate micro services for them and not just monolithic to micro service migration but if we are developing a green field project also we need a set of rules to decide how to bifurcate functionalities into different services for this purpose we first start with applying domain driven design so here we follow our object model first approach so we start by examining our database and we try to find out how the data is represented in that database how the data is divided into different tables how the tables are related to each other and then we try to identify domain models based on real world models so suppose we had these tables in our database order order transaction order address order instruction payment payment transaction payment providers inventory inventory quantity inventory details so based on the above rule we can clearly identify three domain models here which are order payment and inventory and once when we have identified our domain model then we can move forward to defining our bonded context so the context in which domain driven design is applicable is called a bonded context it can be understood as a group of domains or sub domains where there is no conflicting models in between them some sub domains may be shared across different bonded context and in each sub domain they will have a different meaning or a different relevance in that bonded context so a bonded context in other words can be set as a logical boundary in which a group of domains and subdomains live so a bonded context can be modeled into one or more microservices depending upon the number of domain objects involved but a microservice will never be coupled with more than one bounded context to understand this mode let's take an example where we have identified the following domains and sub domains in our project for example we have the order domain we have the payment domain we have the catalog sub domain and we have the inventory domain now when we go to define a bonded context called sales we find that it is using the order domain it is using the payment domain and it is using the catalog sub domain as well and when we go ahead to define the next bonded context which is inventory we realize that it also uses the catalog sub domain along with the inventory domain so the catalog sub domain is present in both the sales and inventory bonded context but it will have a different relevance in both sales and inventory for example in sales it contains details specific to orders for example in a particular order how much quantity has been ordered at what price it has been ordered and in inventory it contains details specific to inventory for example description quantity available to be sold its price and these kind of informations and now as explained earlier a bonded context may contain one or more microservice so the sales bonded contacts here will have two services which will be the order service and the payment service and the inventory bonded contacts will have one micro service which will be the inventory micro service so you see bonded context is the domain model to which a micro service is bonded to in this example the order service is bonded to the order domain in the sales bonded context and the payment service is bonded to the payment domain in the sales bonded context and similarly the inventory services bonded to the inventory domain in the inventory bonded context in other words you can also understand bonded to as owning or taking responsibility of the data and integrity of the data so the order service takes responsibility for the order related data and owns the order related data and maintains its integrity similarly other services maintain the integrity of their domain objects data so this way by developing microservice according to domain models and bonded context we promote microservices features like independence and decoupling there are other advantages of moving to microservices as well for which you may watch our video on strangler pattern which talks about the benefits of microservice as well as strangler pattern which is you know about the approach the migration of a monolith application to microservices the link for it is given at the top of the screen so once again friend thanks a lot for watching this video and if you like this video don't forget to give it a thumbs up and subscribe to our channel for more such relevant videos

Channel: SPS Tech

Views: 7,355

Keywords: bounded context for breaking model, bounded context breaking model, bonded context, bounded context microservices, bounded context, domain driven design microservices example, domain driven design bounded context, bounded context in microservices, bounded contexts microservices and everything in between, domain-driven design bounded context, bounded context ddd, bounded context vs subdomain, bounded context breaking modle, bounded context for breaking modle

Id: xjx4Zkh0NDU

Length: 6min 10sec (370 seconds)

Published: Mon Mar 21 2022