Domain Centric approach
Domain Centric approach
Adopt a Domain Centric Approach first, followed by Data Centric Approach
Status
-
Proposed -
Trialing -
Under review -
Approved -
Retired
Context
We need a consistent way to model a business problem to build a set to services, instead of building a set of services and looking for a business problem. We need a consistent way to promote and communicate what is the primary driver.
Decision
Use a domain first approach, model the systems around the domain and business value they provide. This natural way will eventually prove more beneficial when compared with approaching the problem them as pure data or technology partitions. In essence, discover the data architecture, data flow, partitions and separate concerns as the result of this modelling exercise instead of the other way around. We realize that this may appear to be counter intuitive to the "separate data from applications", however it is encouraged that we take a domain centric view first and then go about drawing boundaries and layers. That would provide for the natural way the business is organized and functions, and more importantly it will also help us realize what is the core domain (that a product line wishes to stay ahead and be a differentiator and has a direct value to the business) and hence where one must focus the resources.
Rationale
-
The realization of the business value or otherwise, defines the outcome of the exercise (success or failure). And hence the success or failure can easily be measured and measured fast
-
The approach provides for a high cohesion and loose coupling. As the domains gets divided into smaller units (sub-domains and realms), the concerns are better grouped and encapsulated from each other. In the resulting system of sub-components, each concerns reflects as "services" . This naturally leads to the microservices style development and can be developed at scale.
Consequences
-
Not everyone has the detailed view of all sub-domains - it is possible to get locked and promote one's own service as the "Core" service. It is fundamental to identify the Core service per domain/sub-domain early on. And this Core service should reflect the goal/objective that is set for the domain/problem-space.
-
The "data" might get locked and may not be discoverable outside the sub-domain. This is true and is indeed by design - strongly advocated by the Sam Newman in his book. The fear of lock-in can be mitigated by publishing all the relevant data for future analytics and discovery.