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?

  • This sounds like an inheritance scenario, not a DDD concept per-se. In other words, Expert IS A Party; Lawyer IS A Party. Party would contain the functionality that is common; each sub-class would contain the functionality that is specific. Jun 23, 2021 at 16:14
  • @RobertHarvey Correct indeed. I was just wondering if this would affect DDD in any way. Since I'm sharing the concept of an address or a contact person to one or more aggregates (depending on the implementation of the inheritance)
    – Jesse
    Jun 23, 2021 at 17:50
  • I don't see how. From here: "the Blue Book of DDD is not a book that gives you recipes about how to implement things but is mainly about how to think and how to talk about the domain, the problem space, and how to start and develop a model as a solution space." Jun 23, 2021 at 18:09
  • And from here: "DDD is not architecture.... You can use different styles of architecture (Hexagonal, Layered Architecture, CQRS, etc.) to apply DDD." Jun 23, 2021 at 18:13
  • 1
    The way you solve that is to evaluate those DDD rules based on your software's specific requirements, and then decide whether or not you need to break those rules based on practical concerns. Jun 23, 2021 at 18:26


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.