First some background. Let’s say we have a system where a customer is placing an order in a web interface. The items that customer is ordering can priced in various ways. Sometimes including the cost of delivery and sometimes not at all. That pricing effectively depends on a variety of factors including the vendor’s own pricing model, that vendor’s individual contracts with customers as well as that vendor’s contracts with its own suppliers. Let’s assume that once a customer places an order for a particular item and chooses a contract if any, the method of delivery can be determined by variables on those contracts. Those delivery methods also live in their own table in the database and have various properties consumed downstream.
It makes sense that a cross reference or lookup table would store that information. That table would be loaded into the domain and could then be used to apply the appropriate delivery method while processing the order.
Does this make sense in the context of domain driven design? Or is my thinking too relational? Is this logic that should be built into it’s own class/method (I mean beyond apply the cross reference table data)?
1
Tables rarely belong in a domain model. Your domain is what changes most frequently, and thus should preferably be persistence ignorant.
It sounds like you might be missing a concept in your domain. I’d recommend following your last path of thought by encapsulating this logic in its own class/method. However, if you’re doing domain-driven design, remember that it’s more about modelling than coding. You should bring this up with your domain expert, and identify what kind of role this concept plays in your domain.