So, as mentioned previously, we had just gone through our first iteration of inserting and then altering the metadata in our tables, and along with forming an initial resolution for our permissions requirement, we had also achieved our first milestone with this new method of design. Now, you might be saying, “But that only exemplifies a data model. Big deal…what about designing the actual functionality?” Of course, we need to design that as well, and as you will see, there’s no reason that we can’t apply the same method here. However, in designing the flow of the functionality, we will need to design the execution blocks (i.e., a high-level view of the functions).
After achieving some success with the permissions issue and subsequent others, the various stakeholders reconvened to address the very subject of the functionality in our architecture. In this particular case, we needed to review established business rules that would validate product data before saving/persisting it, and these rules were cryptically embedded into some COBOL on our legacy systems. After I had spent days deciphering most of it (and hating every moment), we sat down to scrutinize and then approve of my translation sans a Rosetta stone. Initially, I was going to present these business rules as just simple random pseudocode, but since I’m a big fan of code reuse, why not somehow build upon our previous meetings and incorporate the metadata from those newly created tables? So, using XML, I created a markup language of my own that utilized our attributes and fields, still white-hot from the forge:
<!-- In this case, AlphaInd is an attribute -->
<if description="Alpha Case Product">
<eval>(AlphaInd) == ('Y')</eval>
<!-- description="Alpha Required Fields" -->
<failure_message>Alpha Product has a missing field (or the title’s length is larger than allowed). More than likely, a Price attribute is probably missing.</failure_message>
<success_message>Alpha Title has all fields!</success_message>
In this example, for any product flagged as an ‘Alpha’ product, we would ensure that certain fields had all of their respective attributes populated. In addition, it would look at the attribute ‘Title’ (of the field ‘fieldTitle’) and ensure that its length wasn’t longer than the maximum allowed. On success, it would return the text from ‘success_message’, and in the case of failure, it would return the text from ‘failure_message’.
I had taken the incremental step of creating metadata in files that referenced our metadata in tables, and even though it existed in something other than SQL columns, it was yet another milestone for our new design method. Before the meeting, I was somewhat apprehensive about the reactions of some of our stakeholders, but quickly, it became clear that I had been mistaken about my concerns. Nearly all attendees immediately grasped the rules being presented, since it was simply an additional layer to the language established with the metadata in previous sessions. Amid the enthusiasm, some people began to ponder other possibilities, like placing the business rules in a set of tables…but, after I explained the difficulty with such an implementation, that idea was gently placed to the side. (That’s not unexpected, since excited people holding a hammer will see a nail everywhere.) Even though other suggestions were made and discarded, I was enjoying the palpable enthusiasm in the room. We had found a cadence with this method, and we were making progress. I and a few others considered again how we could develop an architecture around this metadata, with properties in database tables and flow in markup files. Even though each ponderance about the possibility brought a fearful jolt, it was slowly appearing to be less crazy of an idea.