Say I have an Delivery class which should have a Destination property (among many others). Destination can be an Address (country, city, address line, post code) or a Port (international code, name). As you see these two types do not have any overlapping attributes. The only thing they have in common is Destination string which should be generated from their attributes and displayed in GUI or sent to printer. What is the best way to model this in DDD context? I have considered the following approaches so far but I am not fully satisfied with either of those:
Delivery class has two properties for both destination types + discriminator property which specifies which property of the two is not null.
- Clients of domain entity have to know about this structure and make a decision which of two Destination properties to use based on internal property of Delivery. This seems like domain logic leak to me.
- Both destination types implement common interface (IDestinaion) with single method GetLabel(). Delivery class holds property of IDestination.
- Label might be GUI platform dependent (new line in HTML vs console) so I really don't want to hold this logic in domain object.
- Two Delivery sub-classes with single repository.
- This one is similar to the first point: client would have to know which subclass they are dealing with and do a type unsafe cast to form a label.
- Two Delivery sub-classes with two separate repositories
- Seems like a lot of boilerplate code. Also services would have to run queries on both of these repositories as delivery subclass objects would have to be used as uniform objects in most of the use cases.
Which one do you think is the best approach? Maybe there are more designs? Any solutions to the disadvantages that I articulated?