I’m going to tell you one of my Software Design secrets.
In your life as a Software Developer, it always comes the time when you are required to model dynamic runtime behavior.
Rule Engines, Business Process Automation, KPI Calculation.
Those are all examples of domains where you can always find two fixed subsequent moments:
- the definition of some kind of rules, formulas or actions;
- the runtime, when a definition is evaluated in reaction to a specific event to produce a predefined outcome;
Take a Rule Engine.
Someone needs to define a Rule before it can be executed at some point later in time.
Now let me ask you a question:
The definition of a rule and its runtime behavior should be modeled in one single place?
I used to do that, and it was painful.
A class representing something like a Rule would end up with properties and methods that were used only in one of the two moments, the definition or the runtime.
The model was working, of course, but it was confused and cluttered.
I was always trying to normalize properties and behavior between the two use cases.
The cognitive load to introduce a change, while ignoring the unrelated parts, was constantly increasing.
I started to think that there was a great opportunity for a deeper insight into the model.
And indeed I found it not long after.
I realized that a same entity, when used in two distinct moments, requires two different, separate models.
Put in other words:
When the domain calls for dynamic, contextual behavior, you should always have two separate models. One for the Definition and one for the Runtime.
This is actually a pattern that I saw multiple times now.
It allowed me to achieve a sophistication and elegance in the resulting code artifacts that I could never achieve with a single model strategy.
Acknowledging the separation between the moment of defining something and the moment in which this something is applied to contextual data gives the developer a considerable advantage in expressing a powerful model with a deeper insight into the domain and an optimal disposition to further breakthroughs.
I think this concept is quite ubiquitous and can be applied to many domains.
That’s why I felt the urge to give it a name.
Initially, I went for Temporal CQRS, but I was not satisfied with the C and Q still being there despite being out of context. I was also afraid of the confusion such a name could generate.
The final version came from me wanting to retain the bond with the duality of CQRS for easy recalling and at the same find a proper name for the duality elements.
Eventually, I opted for:
Definition Runtime Responsibility Segregation.