0

We are working on several products as the IT department and we try to provide solutions for different departments within the same company. The core of our business is insurance and the main goal is to have automated processes for brokers, back-office people, and finance department (there are some other groups, but it is worst to mention only 3 for now). When we started working on our products, we identified 2 bounded contexts (that cover only the business we are working on at this moment).

In our bounded contexts we have the following core concepts:

  1. Insurance Policy Proposal - what our clients provide (propose) to our brokers to get an insurance policy
  2. Insurance Policy - it is a document that provides proof of having insurance coverage for a person (or group of people)

When a proposal is submitted by brokers, it is passed to back-office people who must review and verify what was provided in the proposal. If everything is ok and there are no mistakes, the proposal will become an insurance policy. As you can see we have two different departments:

  1. Brokers create/manage and submit proposals
  2. Back office people review proposals and manage policies after moving proposals to policies

If you want me to share something about the content of proposal and policy, they are almost identical in the beginning and the first version of the policy will have the same attributes as the initial proposal has.

And we have some kind of feeling that proposals (and everything around) belong to one sub-domain and policies are the part of another sub-domain. At least we have the following signs of that:

  • Both terms/definitions are used by business
  • The first concept is managed by one department, another one is managed by another

Could you please help me to understand how we can make sure that our hypothesis is wrong or right?

2 Answers 2

1

I spent several years in the insurance industry in the US. So, I'm familiar with the space. It sounds like what you are talking about is a system that would allow brokers to create proposals that are then handed off to back-office staff for underwriting. If so, I've written a system very similar to that.

In the system my team built, there were quotes and policies. Brokers requested quotes by entering a consumer's information into the system. An automated underwriting system responded with a quote. If the consumer accepted the terms of the quote, then and only then was a policy created.

Quotes and policies were managed by different systems, and different departments. There were similarities in the data structures. But, there may be significant differences. At a minimum, there are differences in the regulatory requirements for each. That in and of itself may be enough of a reason to separate the concepts.

2
  • Thank you for your reply. I also have the same feeling working on it. Do you have anything like links to articles or a chapter from a book that can be used as an example for my colleagues and business people? Mar 18, 2019 at 7:21
  • Unfortunately, no. Just my personal experience. Mar 18, 2019 at 7:43
0

I've experience working on a loan system with a similar set up. Quotes generated via broker/front office and Loans generated and maintained on approval. Though that is far from one way, Loans are pulled back into a quote for amendment, and the updated quote can be applied to the Loan.

The reason you are seeing similarities is because they are the same object at different points in their life-cycle. They will of course share much of the same details because in your case it is a Policy that is generated from the data contained within the Proposal. If your system permits amendments then its natural that Proposal may be generated from Policies.

The difference is around the behaviours. Proposals obviously do not bill customers while policies do, and policies must be maintained/rolled over to new policies each year while a proposal does not automatically update. By extension those behaviours will create/maintain separate data as well that is not needed in the other system.

The way to test your hypothesis is to imagine not having the boundary and treating them identically, vs keeping the boundary (or any other set of boundaries).

  • How much extra data must be maintained that serves no purpose for the state of the proposal/policy? (Include optional data as if it exists, you want to know the potential)
  • How much behaviour is there that if activated in an incorrect state represents a High incidents, medium incidents, low incidents? (Billing a proposal, Editing a Policy)
  • How frequently does the state of the proposal/policy change? (How stable is each state?)
  • How many downstream/upstream systems are interfaced?

Compare the answers of your merged domain, with those of the separate domains. Generally there is a clear winner, otherwise you will need to consider how the system is likely to evolve to get a clearer answer.

1
  • Sounds like what I expected to hear. Thank you for recommendations Mar 22, 2019 at 7:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.