Domain model for an optional many-many relationship

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.

Answer 2

What would be a good way to model this that makes sense from a domain model perspective?

Your third option sounds the best, by virtue of its simplicity:

Person.PhoneNumbers // a list of phone numbers
PhoneNumber.Person  // references its parent

How do I avoid misplaced properties (DisplayOrder on Person) or conditionally populated properties?

Is DisplayOrder arbitrary, or is there some domain meaning embedded in it, such as the date it was replaced by a new phone number? If so, I'd change the attribute so it expresses that meaning. That is, don't store the display order in your database, store the information you need to construct the correct display order and let your views order them, perhaps using a strategy defined in your domain model. (For example, a StandardDisplayOrderStrategy might show 1) home numbers, 2) work numbers, then 3) mobile numbers.)

As for conditionally populated properties, consider populating them all, all the time.

Answer 3

Make the Join-Table a separate class, e.g. PersonalPhoneNumber:

• PersonalPhoneNumber has two fields: One Person and one PhoneNumber
• Person has a list (java.util.List) of *PersonalPhoneNumber*s
• the ordering of the list is what you wanted to express as DisplayOrder
• PhoneNumber can also have a set of Persons