The anatomy of a Pattern (part 1)
The people that work with Genio everyday end up talking about this concept of “Pattern” as if it was like the air they breathe. It’s just a thing that allows other things to be generated from it, and for those in that development cycle that is all the knowledge they need.
However, as new people come into contact with Model-Driven Development (MDD) it becomes very apparent that this colloquial definition of “pattern” is not sufficient for them to understand the extent of the implications that a pattern imposes, or even how to turn that into concrete and functional use of said pattern.
This will be a 3 part series, with this first article focusing on the goals of a Pattern, the second part where we introduce a more formal definition for a Pattern, and in the third article we will talk about how all these concepts come together into an MDD platform.
Hopefully, with this article series, we can help make things clearer and raise the effectiveness of communication to newcomer practitioners of MDD.
Goal
Patterns aren’t created just because we feel like it. There is an inherent utility that drives the creation of a pattern.
Here is a list of things that add to that utility:
Is this thing an observable repeated task for your developers
There is an identifiable begin and end to that task
The task has to be redone in multiple contexts
There are sets of (necessary) variations each time the task is performed
People often copy previous artifacts and reengineer them for every new task
An artifact is just the end result of a task, it’s what gets produced and kept to be delivered to either other task or even as the end product to a user.
At this point it's easy to mistake MDD with automation, and indeed automation is the end goal of MDD, but it builds on it with a crucial concept:
We are not looking to automate one task, we would like to automate the entire class of problems that these tasks were originally solving. I.e. we are not looking to automate building a car for model X of brand Y, instead we are looking to create a production line that automates building any kind of car (or at least, as many kinds as possible).
Furthermore
a Pattern in MDD aims to:
Clearly define the scope of problems that it solves
Objectively identify the variables of the problem, the range of those variables, and the consistency of their values
Abstract the set of tasks into one single Linguistic concept that can be used between developers to mean one specific desired end result
Ensure that when used together with other Patterns, the side effects are predictable and have Linguistic coherence.
Example
To better understand all these guidelines lets analyze an example. To make things easy and relatable let’s use the quintessential MDD pattern: Creating an ORM layer.
The utility of creating a reusable Pattern for an ORM should be easy to understand: Developers have to develop new ORM layers each new project and know the set of code classes that need to be created. Also, each entity needs to be coded slightly different, and the properties of each entity have a huge amount of validation, to the point that each property type can be considered a Pattern of its own right. You end up observing developers copying previous project setups, or even copying similar tables and changing fields accordingly.
Next, you find out that each developer likes to put his own spin of the field type used, older projects use older API’s and your 10 production systems so your developers need to wade through 10 different documentation versions. Plus, the code is boilerplate and boring so it’s not long before you push the grueling task to interns and lower skill developers.
Seems like this is the correct time to start thinking of shifting your team to spend their hard work to create a Pattern.
The scope of problems you want to solve is to build any data layer that any project might need, or at the least all the projects you have experienced in the past and plan to take on in the future.
You will need to add options for table names, field types, field sizes, some way to establish relations between 2 tables. Decide if you want to model foreign keys explicitly or abstract N:N relations (relation arity). Decide if your model needs to deal with uniqueness and null fields. Every decision your developers made needs to be identified and find its way into the model definition you are constructing.
Then you decide the names you will give to the patterns and properties thereof. Do you call it a Table or does Entity better represent the scope of your abstraction? Spend some time here, this name will stick with your model for years to come, so it’s important to be something everyone understands its meaning quickly and as unambiguously as possible.
Finally, look at all the other Patterns you already have, if you already have a Pattern for interfaces then they surely will need a way to reference your brand new Entity model. Identify those points of interaction sooner than later and you can get interesting results like for example referencing a field inside a Pattern for a List means you want to have the database queries boilerplate generated instead of developed.
Next
In Part 2 we will formalize this definition for a Pattern, so that once you know what you want, you can say what you want to your MDD platform.
