How to use data from another bounded context

Question

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.

1. 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.

2. 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.

3. 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?

Answer 1

DDD is not a methodology to break up a monolith. It's a methodology to write code that speaks in the same language as the experts already in that domain.

What I see you doing isn't a DDD thing. It's a microservice thing. You could stick with DDD and break things up with aggregate roots but that's still a monolith.

To break up a monolith you have to write different executables to do different things. These separate things can work together but they can't be one big mass that is only separated when you look inside.

In the microservice world each thing can be a service that all could live on one device or each on many devices. Each thing is the single authority on whatever it is. This lets you segregate the whole stack. You don't have to do all this on one device, on one database, or in one language.

A bounded context doesn't offer that. A bounded context means it's clear that "eligibility to elect" is about insurance coverage and not voting rights. Why? Because you're not mixing two different domains together that use those words differently. Which is fine. You can do that. I just don't see you talking about that.

Answer 2

A DDD bounded context is a boundary within which ubiquitous language is used — everyone agrees on the vocabulary and their specific meanings.

On a very, very large project it is difficult to achieve ubiquitous language across the entire scope of such large project, so DDD acknowledges this and advocates separate boundaries each with their own ubiquitous language.  To cross these boundaries you need some mappings.  If you have multiple suppliers & vendors in a huge ecosystem, each with their own focus & concerns, this would merit multiple bounded contexts.  The travel industry, for example, which concerns with transportation (car rental agencies, taxi companies, airlines, brokers, hotel chains..).

The bounded context is not the only unit of modularity in DDD.  Aggregate roots offer modularity and independence within a bounded context.

If you're breaking up a monolith, there is no need to go directly to multiple bounded contexts.  You should perhaps first try to define identify (independent) aggregate roots while assuming a single bounded context.

Answer 3

I'm trying to get some best practices on how to use data from another bounded context.

These are some methods for sharing data between bounded contexts.

And as you can see from top to bottom level of co-operation will raise. Therefore Anticorruption Layer needs highest level of co-operation between bounded contexts.

So depends to the situation either of above methods can be used for having indirect access to the data of another bounded context.

You also may find this post(Sharing Data Between Bounded Contexts in DDD) useful.

p.s. I did have above picture in one of my old power-points, if anyone knows it's reference? please mention it as comment, thank you.