Definition Runtime Responsibility Segregation

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:

1. the definition of some kind of rules, formulas or actions;
2. 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.

Two distinct, separated models. One for the Definition, 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.

Ready to become a better developer?

I’ve created a developer toolkit for you. Download it for free and start learning how to write code you will be proud of. If you constantly apply those techniques, you’ll become a top software developer.

Get the free developer toolkit here!

If you enjoyed this post, please click the 👏 button and share to help others find it! Feel free to leave a comment below.You can also subscribe to my Software Development newsletter here: http://eepurl.com/dfQQaz

Definition Runtime Responsibility Segregation was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.