Using a Domain Driven Design Approach to manage complexity
When it comes to business modelling, the approach has evolved over the past couple of decades. Around the milllenium we were building models of the entire enterprise, and ending up with vast, unwieldy diagrams that were complete, but virtually useless, and often out of date within weeks when some depertment was restructured or changed its processes in some way. Domain Driven Design is the result of the experience of building such models. In summary it breaks the monolithic “Enterprise” model into a smaller set of “Business Domain” Models. Every enterprise consists of a number of smaller business domains, each of which has a high internal cohesion, but a lower level of dependency with the other business domains, so for example the accounting depertment might share the customer entity witha number of other domains, but the account, line, item and Year End entities associated with that customer would be specific to the Accounting domain and not visible to any other domain.
Bounded Context
Bounded Context is the focus of DDD’s strategic design process which is concerned with managing large models and teams. DDD deals with the complexity of the modelling process by dividing the models into different “Bounded Contexts” and being explicit about the relationships between each context.
How to develop a DDD
To develop a detailed DDD is best performed as an interative process. First define the business domains and the key business scenarios for each domain.
Run a series of workshops with the domain experts (Usually the senior users of existing systems and their line managers)
Build a set of domain models for the key business scenarios – the happy path and common, expected exceptions
Identify the shared business entities vs the domain specific entities.
Identify the domain specific business processes.
Model the enterprise as shown above in the “Bounded Context” section, identfying the interactionsbetween domains, but treating each domain as a black box at the high level.
Model the specific domain(s) which are of interest to the project. Build detailed models of the domain as necessary to fully understand the entities and processes that comprise the domain.
Use these models to drive your microservice architecture development.