I am looking to see if there is a general design pattern or strategy to handle a use case I see often in our codebases. My best attempt to generalize this use case is "Map permutations of n parameters to a specific value, and look up the appropriate value when provided those parameters."
Due to high cardinality of some parameters we prefer not to spell out every single permutation of parameters with a massive truth table. In fact, we often have negation configuration (e.g. return value ABC when parameters are NOT permutation XYZ) to avoid such a massive truth table. Parameters can be optional during lookup. Also, sometimes we add new parameters.
For example - imagine you want to store a "support phone number" value for your store's customers. This is influenced by their country of residence, average spend, and primary language. With 100 supported countries, 3 spend categories, and 15 supported languages, we would have to enumerate 100x3x15=4500 entries in this truth table to fully capture all permutations. In our real use case we see far more permutations than 4500 but this gives you an idea.
In reality, rules exist like "always use phone number 555 555 5555 if language is French", or "in Canada it is illegal to provide different services based on annual spend, so spend will not change the phone number provided". We take advantage of these rules to short-circuit lookups and avoid having to create a massive 4500 entry truth table.
In our code we accomplish configuration storage and look-ups like this with disparate JSON schemas and custom code for each instance. Is there a more general pattern/tool to handle this flow?
Aucun commentaire:
Enregistrer un commentaire