How do we use domain driven design to come up with microservices boundaries and implementation details?
Role of technology is to derive the business outcomes, improve business performance and make it easy to adapt to the changes in the needs of the end consumers.
Domain driven design lets you focus on the system as a whole, identify focus areas to create business differentiators and adapt to the changes in future.
Starts with understanding the business domain i.e. Problem space. Business model canvas, event storming, formal & informal interviews of domain experts leads to a good understanding of the problem space. This process is also known as “Knowledge Crunching”.
Having one domain model for the entire business domain is not appropriate and very complex and hard to maintain. Hence the system is divided based on business capabilities, key activities, transaction consistency and unified model having a common & unambiguous language. These subdomains or the business contexts are called Bounded contexts and the common language within that context is called Ubiquitous language.
Bounded contexts can be classified into core, supporting & generic subtypes to make the “build vs buy” decisions and highlight the focus areas. Core business contexts being the business differentiators.
Bounded context works in collaboration with other bounded contexts and external services to meet the business goals.
Having multiple bounded contexts with their own ubiquitous language are the Strategic patterns of domain driven design.
Next steps involve identifying Domain entities [Uniquely identifiable business objects], Value objects [With no conceptual identity by themselves unless they are associated with an entity].
Various domain entities & value objects are grouped together to construct the whole object from the business domain perspective which is known as Aggregate. An aggregate has a root identity and implements business processes.
Repositories are created to implement the persistence of the aggregates. It keeps the aggregates away from the storage layer, also maintains automaticity and consistency.
Domain services are defined to implement the business process that doesn’t fit to an aggregate naturally and involve participation of multiple domain objects and external services.
Application services and infrastructure services are defined to implement processes (E.g. creating dashboards, notification services etc.) that don’t relate to the business domain directly.
Domain events and integration events signify the state changes in the domain model and cause the services operation to be triggered.
Domain entities, value objects, aggregates, repositories, services and events that help in implementation of microservices are called Tactical patterns of domain driven design.
Originally published here: https://www.linkedin.com/feed/update/urn:li:activity:6951797558897700864/