"Link Object" concepts - yay or nay?

How do you think about when the linkage between two concepts deserves its own concept, vs just being part of those concepts?

For example, consider an online food ordering app.

  • Dish is a concept.
  • Order is a concept, containing say a Customer and a list of Dishes.
    But the dish-related information Order is actually not just a list of Dishes. Each line item in the order might also have a quantity (e.g. 3x Fried Rice), amendments (hold the onion), etc.
    So does something like OrderLineItem deserve its own concept? This would seem to violate the idea that concepts should be independent, since OrderLineItem doesn’t really make sense on its own outside the context of an Order.

What patterns have you seen work well here?

Hi @mjw : Sorry for missing this and only replying just now. These concepts that you list are more like the entities or object classes of an OO design. Concept design is very different in how it modularizes behavior. Rather than associating behavior with objects, it groups behavior by purpose (or what people often call “concerns”). So in a food ordering app, the Order concept would include the items and their counts, and you’re right that there wouldn’t be a separate concept for an order item.

Amendments are really interesting because without them Order would be generic (and not even be about dishes, but about any type of item).