Even though I plan to eventually write a longer piece about the subject, I should mention here that metadata-driven design thrives in a certain context, but it may not fit many situations. For the working example mentioned in previous posts, it was very productive in our efforts to create an engine. However, it’s important to note that this particular method and design could be less helpful in the case where other developers are looking to interact with our project. For example, another group of developers may merely wish to conduct simple interactions with the created system, and the return on investment may be low for taking the time to learn the idiosyncrasies of such an environment. In that case, it would be fine for the system’s creators to create a library of strongly typed classes that could be employed by external developers, so that they may engage in a straightforward way with our metadata-driven system. However, there’s one fairly obvious prerequisite to that situation: these strongly typed classes would need to be eventually transformed through an intermediate layer, so that they can become more generic classes and be fed into the system’s engine. In that way, you can have a developer-friendly layer without interrupting the flow of your architecture. There are a number of ways to accomplish this goal, and in the near future, I hope to write about some of them.