Even though I haven’t yet addressed a specific guideline when it comes to practicing MDD (i.e., metadata-driven design), I’ll eventually write more about such idiosyncrasies. For the moment, though, I can assure you that there’s nothing revolutionary about it. After all, as Newton popularized the sentiment, we often find ourselves standing on the shoulders of giants. I find myself in a similar such position, since most of the requirements for MDD originate from domain-driven design. In order to surmise the appropriate metadata for an application, you must outline a domain model for your application and speak about it in terms of a domain-specific language. In fact, metadata is often a direct byproduct of data-driven design. The key difference between DDD and MDD (besides the former being the parent of the latter) is that metadata-driven design is ideal for projects where the team has the luxury of time, resources, and expertise to practice further abstraction, in order to build a solution which anticipates a domain model that will evolve with time. My manager and my colleagues found ourselves with such a rare opportunity, and we embraced the moment. After reading Domain-Driven Design by Eric Evans and putting those methods into practice, we came to such a model for our initial solution:
However, as I mentioned in my last post, we were not quite happy with that arrangement, since it left the configuration as simply data retained in flat files. On its first iteration, this metadata was supposed to be par for the course, with the usual mentions of databases, server URLs, usernames, and passwords. On subsequent iterations, it became more refined as it started to include tables, data points, and the names of stored procedures with business rules. However, as we started to converse and consequently argue about it, some aspects began to be points of contention. For the managers, the idea of trawling through a dozen (or dozens) of configuration files began to fill them with a sense of dread, emphasizing that it would eventually become a terrible mess (which, indeed, sounded likely). Several developers including myself hated our current path of making the metadata into a complete lexicon of our application’s domain, since it would inflate the size of our configuration files and since it would lead to eventual code bloat. Instead, we focused on the idea of the metadata not being static values based in files and instead being dynamically addressed in a set of database schemas and tables. In the end, after we all delivered and received many acerbic harangues, our final design became an unique combination which would satisfy both developers and managers alike:
In this case, by having certain experts on hand and by abstracting the functionality in our DDD solution, we had escalated the metadata from being simply a set of values for a specific domain model to being the fuel for a powerful, more-generic engine. By doing so, the developers became more enthusiastic about the project, since it would be more than a simple CRUD application and would be a true development challenge. For managers, it would become a system that they could understand, manage, and control through simple SQL statements. It would be an ideal solution, if we could build it together. Would we achieve that through collaboration…or would our ending be more reminiscent of The Lord of the Flies? And just how could we build such a thing? Stay tuned for next week’s episode in order to find out.