Coding: Is there a name for everything?
Since I wrote that post weāve come across a couple of examples where there doesnāt seem to be a name to describe a data structure.
We are building a pricing engine where the input is a set of configurations and the output is a set of pricing rows associated with each configuration.
We modelled the problem using a List of Pairs of Configuration/PricingItems:
List<Pair<Configuration, PricingItem>> configurationToPricingItems = buildThoseCombinations();
We donāt need to do any lookups by Configuration ā just show the results to the user ā which is why we havenāt used a Map.
Our object oriented background suggested that there should be a name in the business domain for this but when we spoke to our business analyst and subject matter expert it became clear that they didnāt actually have a word.
Despite that it still feels strange to have to pass around a List of Pairs but I wonder if thatās because in Java we tend to abstract concepts behind classes rather than because it makes sense to do so.
If we were using clojure then I donāt think weād feel as uncomfortable about passing around basic data structures because the language and the culture around it encourage this. We should only create a type when itās strictly necessary.
In this case itās a data structure to carry those combinations around and we donāt actually apply any logic to the data structure as a whole, only to the individual entries.
We wrote the code about three weeks ago now and havenāt experienced any difficulties in terms of the code being understandable or easy to work with.
Iām intrigued as to whether others have noticed a similar thing or if we arenāt embracing Domain Driven Design fully and need to dig deeper to find a missing domain concept?
Reference: Coding: Is there a name for everything? from our NCG partner Mark Needham at the Mark Needham Blog blog.


