The applications that I work with deal with Group level insurance. The insurance is mostly Life and Long Term Disability. We have a monolith library that all of our applications use at this time. We are thinking of moving more of our application to services and I'm trying to get some information on DDD practices to segment out our monolith.
As an example, two of our applications are a Policy Administration system and a Census Entry system. Policy Admin stores all the information about insurance policies and the clients. The client would be an organization, school, city, county, etc. Some pieces that are tracked are the policy header information, the classes, the different lines of business under the class (For a Life policy, you could have Supplemental Life, Spouse Life, Dependent Life, etc.), how volumes are calculated, rates, eligibility information, etc.
A good representation of our current object model is the following. There are more pieces of information under each object but these are the main pieces.
Client Policy Class Coverage (line of business) Rates Option (how volumes are calculated) Eligibility (whether someone can elect the coverage) Participation (rules on when to enforce requiring Evidence of Insurability)
Our census entry system handles the entry of employees at the client. It also uses the policy admin data to create coverage elections based on the policy, class, coverage and option an employee is electing. It uses the option to calculate and store the volume on the coverage election.
Data model in census entry would be
Client Employee Coverage Elections
It seems I would have two bounded contexts here. One for Policy data and one for Employees and Coverage Elections.
Would I have a copy of the necessary information from the policy admin system that the census entry system needs in order to perform? The concern here is there is a lot of data that would be needed. Most of our data has effective and cancel dates. For example, when an option changes; a new option is created and the old one is canceled. For a particular option there could be a few historical records that would be needed.
Would I have a coordination service that the app talks to. This service handles getting the information from policy admin to do the actions in the census entry system? This introduces a dependency though.
Some other way I'm not thinking of?
I'm thinking that number 1 is the way to go but wanted to get some ideas.
I have another situation where the census entry data and rates are used to generate a bill. For the billing system, would I have copies of the necessary data from both Policy Admin and Census Entry to perform that task?