Currently there's an aggregate root "Party" which for now only can be an insurance policy holder. A party can have multiple addresses, communication addresses (telephone, mail, ..), contact persons.
A policy holder can also have multiple insurance policies, this is a different aggregate root.
However new "personas" will need to be implemented. These contain about 30-80% of the same data fields as the original Party entity. They can also have addresses, communication addresses and contact persons. However upon creating an insurance policy, they aren't allowed to have one.
- Expert
- Lawyer
- Various
- Supplier
- Agent
In short: they contain a lot of similar data properties but different behaviour. The behaviour is very limited as it's mainly keeping track of party and insurance policies.
Question is: should these personas be treated as separate entities because they each have different data sets and tasks/behaviour - even though at this point it's not 100% clear on what their behaviour is.
Or should they be treated as one entity and when creating an insurance policy, check if the party is allowed to have insurance policies?
If they are treated separately how can I share the concept of an address or a contact person between both entities without having to duplicate too much code?
ExpertIS AParty;LawyerIS AParty.Partywould contain the functionality that is common; each sub-class would contain the functionality that is specific.