7

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?

Improve this question
1
  • Perhaps, you can think of and provide more info on how Destination is even used? it may well be that Delivery class is not even "interested" as much in Destination, but there are some other users for the Destination? For example, RoutePlanner may much more interested in the Destination and may need something else in addition to purely "pretty printing" strings. Same applies to Deliveries. Which classes you choose for them depends mainly how they are used, composed, etc. Do not fear 'domain logic leak' if the information is really needed for domain actions or events.
    – Roman Susi
    Apr 1, 2021 at 17:42

1 Answer 1

Reset to default
1

I think the answer may fully depend on the extent in which you need to utilize the Destination property. At first glance, it makes perfect sense to simply define an IDestination interface to handle the commonalities between Address and Port. Like you stated, the IDestination route is perfect for abstracting away the logic necessary to get the required DisplayString, but it does introduce some serious control-flow concerns.

That said, is it possible that you're trying to make the Delivery class to generalized? Or at least, does it make sense to separate the objects necessary for display from the objects necessary for domain operations?

Improve this answer
1
  • Thanks for the reply. I think we are on the same page regarding interface property. Because of overgeneralization and pollution of domain model it's probably my least liked option. Unfortunately, this does not fully answer my question. Even though remaining three options solve overgeneralization, domain model pollution and leave display concerns for clients of the Entity, I am not totally happy with either of them due to articulated disadvantages.
    – M T
    Jul 10, 2019 at 19:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.