Before we had even started the project phase regarding domain-driven design, I was already dreading the thought of collaborating with our management. Historically, there had always been a division of ideas between our managers and our developers, and consequently, poor communication had always been a byproduct of those alternate lines of thought. In some cases, the methods between them were different, but in many cases, the problems could be traced simply to a lack of understanding between the two parties (especially in regard to terminology). Unfortunately, since people often don’t delve deep enough into complex conundrums, our developers and managers hadn’t yet deconstructed our failures in order to recognize that communication was even an issue. In the end, it seemed like it would take a miracle for everyone to sit at the same table and to collectively overcome our inability to collaborate effectively. As it turns out, that miracle would eventually come to us in the form of metadata-driven design.
At one point, we were discussing the need for some of our product data to have complex relationships. Some of our data points needed to be within a particular domain if a related data point happened to be within a different domain. For example, a product could have a subcategory code of “ZZ”, as long as its subject code fell within a certain domain and its category code fell within another distinct domain. In the past, much of this domain validation had been embedded within the code, and for some people, the obvious improvement was to place this metadata inside an organized table. Something akin to:
Which allowed an implementation where the subcategory code “ZZ” could be associated with all of its possible permutations:
“subcategory code”, “ZZ”, “subject code”, “SUBJ1”, “category code”, “CAT1”
“subcategory code”, “ZZ”, “subject code”, “SUBJ1”, “category code”, “CAT2”
“subcategory code”, “ZZ”, “subject code”, “SUBJ2”, “category code”, “CAT1”
“subcategory code”, “ZZ”, “subject code”, “SUBJ2”, “category code”, “CAT2”
Plus, there was an extra set of columns for a possible third relationship someday. It was a more robust solution than the previous one, and it was a decent step towards creating metadata. What more could anyone ask for?
Well, a few of us could indeed inquire further. Curious, we asked the data experts in our group the more important question: how many other relationships resembled this one? As it turns out, there were actually many other examples of this type of relationship within the data, and we needed to account for them. As we huddled over the data schema, a new set of tables begin to emerge from our discussions:
Where the three bottom tables could hold an infinite amount of relationships, and a database view could help condense the tables’ data for the managers. At this point, you might be saying, “So what? You normalized some data. What’s the big deal?” Well, there are several important points here. One, by focusing on the metadata before the actual design of the project, the entire team began to have a better understanding of what this application was actually meant to do. In effect, the metadata had become a transcribed whiteboard of our minds’ vision for the project. Two, we simply started here, but this one incursion led to a whole campaign of building an abstract form of the entire application, especially as we began to employ recursive abstraction (which I will explain later). Most importantly, though, by having these types of detailed discussions, we unintentionally developed a new language and a new grammar about our new system. Much like a domain-specific language for computers, we created a domain-specific vernacular (i.e., DSV) that was employed by our stakeholders. (Vernacular being a good word to use since it’s usually found within conversations about building architecture. Why not use it within the context of software architecture as well?) Our managers and developers actually began to speak this common vernacular, leading to a much quicker comprehension of others’ points and to faster iterations of our design. In that way, we learned how the metadata could construct a language, and the language could help design the foundation for our architecture.