Question

Let’s say I’m modeling phone numbers. I have one entity for PhoneNumber, and one for Person. There’s a link table that expresses the link (if any) between the PhoneNumber and Person. The link table also has a field for DisplayOrder.

When accessing my domain model, I have several Use Cases for viewing a Person.

1. I can look at them without any PhoneNumber information.
2. I can look at them for a specific PhoneNumber.
3. I can look at them and all of their current (or past) PhoneNumbers.

I’m trying to model Person, not only for the standard CRUD operations, but for the (un)assignment of PhoneNumbers to a Person. I’m having trouble expressing the relationship between the two, especially with respects to the DisplayOrder property. I can think of several solutions but I’m not sure of which (if any) would be best.

1. A PhoneNumberPerson class that has a Person and PhoneNumber property (most closely resembles database design)
2. A PhoneCarryingPerson class that inherits from Person and has a PhoneNumber
   property.
3. A PhoneNumber and/or PhoneNumbers property on Person (and vis-a-versa, a Person property on PhoneNumber)

What would be a good way to model this that makes sense from a domain model perspective? How do I avoid misplaced properties (DisplayOrder on Person) or conditionally populated properties?

Answer 1

Option 1 has the most advantages since this is a many to many relationship. Each person will have a list of PhoneNumberPerson objects and each Phone Number will have a list of PhoneNumberPerson objetcs effectively creating two one to many relationships.

Managing the two one to many relationships will prove easier in the long run.

A person with no phone will then be a person whose PhoneNumberPerson list is empty. The inheritance option looks like a difficult one to maintain.

Additionally the PhoneNumberPerson class can carry information like the date that the person started using the phone and stopped using the phone so that it is easy to tell if it is a current phone or not.