Domain Decomposition

A monolithic domain model can be decomposed into different parts based on the analysis by finding dependencies between different cohesive units. This, like finding the aggregates, is an abstract process and I don't know how to come up with a definite process. But there are ways to assert whether the modules resulting from decomposition are useful or not.

As a first task we need to classify domain entities into reference and transactional objects. A closer look at this classification also reveals that transactional objects are dependent on reference objects. What also follows is that reference objects really forms the lowest layer of abstraction in the domain model. In other words it provides us with first level abstraction or module. Reference entities can be further separated into different modules but for simplicity we would start with this. This strategy is also the essence of further decomposition of transactional entities.

Within the transactional entities we can analyze further to understand which part of domain depends on which other parts. These parts are a grouping of related aggregates. Since this is domain specific in order to understand this better lets look at our example. So far our domain model consisted of aggregates like product, loan, meeting, office, branch, salutation, marital status, client, group, payment, personnel etc. From this list we can see that salutation, marital status are reference entities as they don't affect the domain logic. As a step 2 we can decipher that in order to create a loan in our application we need to be able setup products and have clients or groups. Again in order to be able to create clients/groups we need to setup the office, personnel etc. What we are really doing is creating layers within our model based on our analysis of domain and understanding of business processes in them. At the end of this we come up with domain dependency structure which looks like:

<<Picture take all contact, booking and MFI examples>>

There are certain characteristics of our module dependency which are worth examining in detail. These characteristics can also act as a test of robustness of your domain modules.

Background module contains the part of domain model which is not directly modifiable by the user. In our main sample accounting module is an example of this.

Metadata module These are modules which do not form the core domain. These are supporting modules which provide additional information about entities in other modules.

Workflow encapsulation In a given workflow all the changes should be restricted to one functional module. In addition to this the workflow can also result in changes in dependent background modules. From our example we can see that when a loan is disbursed the entities accounting module are also affected by it.

Loose coupling between domain modules The number of entities which have relationship with those in other module indicate the coupling between them. Functional module separation which results in too many references indicates that the lines can be drawn differently.

Notes:

Foreign key dependency but no hibernate mapping.

Database table ownership by modules