A month ago I wrote a post describing an approach my team has been taking to avoid premature abstractions whereby we leave code inline until we know enough about the domain to pull out meaningful classes or methods.

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:

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?