Context Segregation Principle

What is a laminate panel made of?

Imagine a person named Sam who is the sales person of a company selling floor panels.

He knows dozen of various "flavours" - laminate, real wood, vinyl, etc. - and he is able to explain the differences between them to a customer. He knows the pros and cons of each type of panel, and he can help the customer to choose the best one for their needs.

He works in this part of the business about 15 years - he saw how it all progressed and how materials were changing along the way.

Sam was asked by his boss to drive to the clostest warehouse and check a very special order that should be shipped.

"It's a personal thing, Sam", said the boss, "so I need you to check it, personally. This a real wood panel, made from a exclusive, exotic type of wood - African blackwood".

Our hero did it without a further ado.

Sam the salesman went into the warehouse. He was there multiplte times so he knew the place well.

He knew the people working there, their duties and responsibilities.

Sam noticed a warehouse worker who was moving a pallet of laminate panels so he started conversation.

Discussion

Sam: How is it going William? William: Hi there, Sam! Tons of work, you know. What do you need? Sam: Boss wanted me to check an order - something very important for him, hence important for me. William: Got order reference? Sam: Hmm, not really. Boss mentioned over the phone you will know it all. William: Sam, we are processing hundreds of orders each day. It is simply impossible that... Sam: Will, Will...Every person would recognize African blackwood... William: Panel is just a panel - we store and ship thousands of them. I need an order reference, Sam. Sam: JUST A PANEL? William: Does it have extraordinary size? Extraordinary weight? Or maybe it needs to be kept in those advanced conditions? Sam: Extraordinary weight? It has a typical size that goes within the range, but when it comes to exclusiveness... Then African Blackwood is one of the rarest and most highly prized woods in the world, harvested from the Dalbergia melanoxylon tree, which grows in the eastern and southern regions of Africa. Each panel is unique, featuring a characteristic deep, almost black color with subtle purple and brown nuances that create a hypnotic effect in any interior. William: I need order reference, Sam. Can't you call the boss?

This short discussion seemed to take ages. Sam was getting nervous.

How could this ignorant warehouse worker not know what African blackwood is?

Every person working in that business knows how precious, rare and unique this wood is!

Calling boss? If the boss would hear that Sam wasn't able to recognize the African blackwood panel, he would think that Sam is really shitty salesman.

Discussion

Sam: Will, I DON'T HAVE THE DAMN REFERENCE, just show me where exclusive panels are. William: Well, that's not how it works, Sam. We typically do not... Sam: How did you ever made through in a floor panel industry with such incomplete knowledge? William: Floor panel industry? I store things on shelves and pick them up to fulfill the order - that's my job, not to mention restocking...

During this conversation Will was able to receive couple of new orders and reject some of them, as he checked that they had shortage of a specific batches in stock.

Why laminate's color does not matter?

Sam sneaked into the warehouse and started to look for the exclusive panels. As Will told him, he was not able to find them.

At least not that easily as Sam thought.

Finally, he found what boss challenged him to take care of.

Sam reported the progress to his boss and got next orders: "Take one panel and call Igor, the installer. You both drive to the customer and check if it fits."

And then the boss hang up.

Sam organized everything - summoned Igor, took the panel and drove to the customer.

The apartment was really...Breathtaking.

One of the rooms didn't have a floor yet - it was just a concrete base, so that's where the panel was supposed to be installed.

So Sam started the conversation with Igor.

Discussion

Sam: Ok, let's put it on the floor and we will see if it fits, as the boss wanted to confirm. Igor: We have only one panel so how could it not fit? Sam: Pardon? Igor: Installing panels is like a jigsaw puzzle solving - with the difference you can cut them to make them fit. Sam: You must be kidding, Igor... Igor: Not at all! Look over there - there's a curved wall - I would need to cut the panels to... Sam: I know how to install panels, Igor. Igor: Oh really, Mr. Egghead-I-Know-How-To-Cut-Panels? So tell me how to cut and then glue vinyl panels? Sam: When the boss asked us to check if the panel fits, he thought about the experience that it brings. Igor: Oh belive me Sam, putting low quality laminate panels on the ground is a god damn experience...

Once again, Sam was amazed how incompenent people are - if the boss knew that Igor is such a smartass, especially when it comes to African blackwood knowledge, he would never hire him.

Discussion

Sam: Igor, you are not getting the point. Boss wanted us to check if African blackwood matches the spirit of this space, of this room. This color does not like rooms where the light bends in a certain way so that... Igor: Sam, I am an installer. I put panels on the floor. I do not care about the color of the panel, I care about the quality of the material and montaging it properly. Sam: So from your perspective Igor, would the African panel fit this space? Igor: I told you Sam - I am able to make any panel fit any space - whether it is African blackwood, European whiteoak or Chinese bamboo.

At least the discussion with Igor was shorter than with Will.

After experiencing storage and installation perspectives, and frustrations that came with them, Sam started to think about the context of the problem he was facing.

Seemed like he was the only one who truly knew the potential of the African blackwood.

It wasn't a surprise that the boss asked him to check the order personally - Sam's magficent knowledge about the products portfolio and details of each materials was well known in the company.

Sam felt the urge to report back to the boss and tell him that the panel fits the room perfectly.

How to negotiate using a floor panel?

Sam drove to the HQ and went straight to the boss office.

He was waiting for the boss to finish the call, possibly with another important customer.

Finally, the boss hang up and looked at Sam, who was standing in front of his desk.

Discussion

Sam: Boss, I have checked the order personally. The panel fits the room perfectly. It will bring the overall experience to the next levels. Believe me. Boss: What are you talking about, Sam? Sam: Sunlight traverses the executive suite, striking the African blackwood panel with golden precision. Like twilight settling over the savannah, the deep ebony surface absorbs light, yet releases hidden violet undertones when caressed by direct rays. For African wood will make the customer be looked as cheetah sizing its prey, eyes fixated on the hypnotic grain patterns that ripple like tall grasses in wind. Where light catches the polished edge, it creates a mirage-like shimmer—the same illusion that dances above sun-baked plains. Even in the corporate jungle, the wood commands attention, drawing everyone's gaze with the same magnetic pull as a watering hole in drought. Boss: Sam, I don't have time for those salesman games. Did the customer confirmed that the panel fits his "blackness" definition? Sam: Well, there was no customer in that apartement, only a secretary let us in. Boss: So you are telling me that you haven't spoken to the customer yet? Sam: Boss, you told me to check if it fits the experience so I thought... Boss: I said you go there and check if it fits customer's image of this panel - last week we played poker and the guy said that African blackwood isn't truly black and he would never let it be installed in his office. I said I will bring the finest African blackwood panels and install them for free. Sam: ... Boss: He's a big player - he has offices in most of the capitol cities in many countries in the Europe. I really thought he could get convinced and order huge batch of those panels for executive offices.

Boss was speechless - he couldn't believe that Sam was so incompenent.

He knew that Sam was a great salesman, but he didn't know that he is so detached from the reality.

Perspectives?

Ok, let's stop here for a while, dear Reader.

You might be wondering - what the hell have we just wittnessed and how does it relate to software engineering?!

Possibly, the first thing that might come to one's mind is that it was a classic example of a communication breakdown.

Assumptions all down the way which made it all wrecked.

Who didn't experience such a situation in their life or work - where people throw invisible concepts into the discussion somehow expecting that the other side knows what they are talking about?

We could say that the language truly made the difference - all talked about the same thing, but from different perspectives, isn't it?

In this particular toy example, it's pretty easy case as "floor panels" are visible, tangible things - you can touch them, see them, "cut them".

Worse if we move to "abstract" concepts like "processes" - "installation process", "negotiation process", "sales process", and so on.

They might be strictly connected to real, physical world, but still our reasoning, our understanding of them, lies in the "abstract thinking" - as we use language to (im)precisely describe it all. (you might be interested in Language of the problem).

Language might work as a strong signal toward searching various perspectives, as in our tiny tale.

Those perspectives might contribute to totally different thinking about the "problem" - here about floor panels.

Modeling Maturity Levels

In one of the previous tales - Modeling Maturity Levels, we explored differences between levels and perspectives, especially when it comes to "Being/Behaving/Becoming".

If you haven't seen it, dear Reader, I think it's good moment to take a look at it, as we are going to deepen this way of thinking further.

Ok, buckle up!

One of the conclusions was that we might model the same thing using various levels, depending on understanding which leads to proper design decisions.

As in the theme from Modeling Maturity Levels, we were able to observe how various perspectives look at the same thing - "a floor panel".

Looking from different perspectives

Each of the people had a specific concept, a specific abstraction of the "floor panel" in their minds.

Sam could be thinking of it as "something contributing to the experience".

Will could be thinking of it as "something that needs to be stored and gave away".

Igor could be thinking of it as "something that needs to be installed".

Boss could be thinking of it as "something that leverages negotations".

Each perspective brings different context in the game - and as we already know, with context comes the meaning, which brings certain rules, policies and other concepts.

"There is no floor panel"

Is there one, central, universal concept of a "floor panel"?

In a way - yes, there's a physical object that we can interact with, although while interacting with it, we would immediately contextualize our sight toward a particular aspect or aspects of it.

Hence, one would get "Sam's floor panel", "Will's floor panel", "Igor's floor panel", "Boss' floor panel", and more.

All characters in this tiny tale might represent certain roles in the business - sales, warehouse, installation, management.

Each of them segregated "a floor panel" concept into their a particular context, in which they are applying their knoweldge, skills, and experience (you might be interested in The ambiguity of application).

Such segregration is an essence of the abstraction - "focusing on what is relevant, ignoring what is irrelevant".

And the goal is not reusability, but the ability think about the concept in a very specific way (you might be interested in The ambiguity of abstraction).

So if one starts with a central abstract idea of "a floor panel":

public class FloorPanel
{
    public string Material { get; set; }
    public string Color { get; set; }
    public int ExclusivenessLevel { get; set; }
    public (double, double, double) Dimensions { get; set; }
    public string InstallationType { get; set; }
    public double Price { get; set; }
    public double Weight { get; set; }
}

And then taking possible interactions that one can have with "a floor panel":

Sam's interaction - "selling the experience"
Will's interaction - "storing"
Igor's interaction - "installing"
Boss' interaction - "negotiating"

FloorPanel might play various roles, depending on the context:

public class FloorPanel : 
            ICanBeSold,
            ICanBeStored,
            ICanBeInstalled,
            ICanBeNegotationLevarage
{
    public string Material { get; set; }
    public string Color { get; set; }
    public int ExclusivenessLevel { get; set; }
    public (double, double, double) Dimensions { get; set; }
    public string InstallationType { get; set; }
    public double Price { get; set; }
    public double Weight { get; set; }
    // many, many more *properties* and *types of interactions*!
}

Note that I used specific .NET notation for interfaces - prefixed with "I" - if one drops it it still preserves the meaning (but you might be still interested in reading one I think it's a very powerful technique for software design - I, interface).

Until now, nothing has changed.

Let's apply contextual segregation.

Contextual models

Each of the roles that a FloorPanel might play, has a set of specific behaviors related to it, which require only a subset of the "properties" of the original FloorPanel:

public interface ICanBeSold
{
    public string Material { get; set; }
    public string Color { get; set; }
    public double Price { get; set; }
}

public interface ICanBeStored
{
    public (double, double, double) Dimensions { get; set; }
    public double Weight { get; set; }
}

public interface ICanBeInstalled
{
    public string Material { get; set; }
    public (double, double, double) Dimensions { get; set; }
    public string InstallationType { get; set; }
}

public interface ICanBeNegotationLevarage
{
    public int ExclusivenessLevel { get; set; }
    public double Price { get; set; }
}

Of course, some contexts might, and probably will, require certain information to be available to deliver its capabilities correctly.

And this means it might seem that those information are "duplicated".

But the point is that the context is the king - it defines what is relevant and what is not.

a FloorPanel playing various roles

If we could explore each context, it might turn out that there contextual names, related to each perspective.

different names, based on the context

And finally, a FloorPanel might be "created" by composing all of the contexts together - but only when there is a need for such interaction, not just to "have it", but "to use it".

public abstract class FloorPanel:
    Product,
    InventoryItem,
    InstallationMaterial,
    RelationshipToken
    // many, many more *contexts*!
{
    // many, many *properties* and *types of interactions*!
}

Context Segregation Principle

Abstracting, by definition, means that one cannot model the "reality".

Central concepts like User, Product, Order or Appointment lure us into such thinking as there are "visible" - during conversations and in our software.

People speak about them as if there were "tangible", almost "touchable", but those are just shortcuts to the real abstractions that are highly contextual.

In our work, we might be tempted to create a single, unified model that would cover all possible interactions, all possible contexts, all possible perspectives.

But we all know where does it leads - to models behaving as the "god object", luring into a muddy terain where everything is connected with everything.

Instead, we should focus on segregating the contexts, by taking into account the usage, the interactions with "a concept", and then model it accordingly.

Operations, actions, behaviors, ways of interacting, are going to guide us toward information needed.

To me, this is one of the most important aspects of Domain-Driven Design - thinking in terms of contextual models, each specialized in solving a particular problem or a set of problems.

Such contextual models can provide answers to questions, behaving as an authority, an expert, for a particular (sub)area of the business.

Playing a role of a single source of truth.

Conclusion 🔍

Different contexts require different abstractions of the same concept, each emphasizing only what is relevant to that specific perspective while intentionally ignoring what is irrelevant.

Probably nowadays no one would create a single abstract class FloorPanel, implementing strangely looking abstract classes or interfaces (I hope so, dear God).

Instead, there will be a way of composing all contexts by using an identifier:

all contexts connected through a single identifier

One could say that in a way a FloorPanel stopped existing, even though people might still use this term in conversations.

Kind of Schrödinger's floor panel - existing and not existing at the same time.

So what?

Some of you might think: "no way it can be practical, Damian"

We should probably define what does "practical" mean in this context (pun intended).

I don't think it will help you improve your deployment pipeline.

Same with the way one runs database migrations.

But can such a way of thinking help when doing modeling and software design?

Think about it, dear Reader, what is your "floor panel"?

Do you have a model that combines many perspectives, includes many contexts, and plays various roles?

What would happen if you would segregate those contexts, and model them separately?

In DDD, there's a concept of a bounded context.

Bounded Context (one of possible definitions)

An area inside which a particular model is applicable

It represents our way of solving things, stressing out the importance of the language, the meaning - hence the abstractions.

Thus, one could say that within a specific bounded context, contextual models live.

What would be the level that one is going to build those contextual models - that's a different story.

And that's where truly Domain-Driven Design really shines - we need to orient our thinking toward business (sub)areas to see problems contextually, find perspectives and seek for proper abstractions.

Some of the problems might involve transactional processing, some of them might be related to timeseries analysis, and others might be linked to handling everchanging business rules.

Each of those problems require highly specialized, contextual model - a solution that can answer important questions posed by the business.

Contexts, not Domains?

You might be wondering, dear Reader, why I phrased it as "Context Segregation Principle", especially when I strongly relate to Domain-Driven Design.

Shouldn't it be named as "Domain Segregation Principle"?

I was playing with the idea for a while and it seems to be that this "principle" directly corresponds to Bounded Contexts - we design them by organizing boundaries and assigning responsibilities accordingly.

As we are consciously doing so (hopefully), it means that segregation to contextual models also is an act of a designing, whereas "domains" are there - to be explored, to be understood, to be interacted with to provide those models, so that we are able to satisfy business needs and solve business problems (and make frigging moneyz!)

I considered also naming it as "Abstraction Segregation Principle" but it seemed to be too abstract (pun intended), and kind of disconnected from the business.

What's next?

Go. Go, observe and try to find your "floor panel", dear Reader.

I know that I left you without any tools, any heuristics or any guidelines.

If I could give one starter advice, it would be to look for the behaviors and ways people interact with the concept.

Behavior (verbs) carry the context. With the context, meaning comes. And after meaning, rules appear.

And rules, in order to be satisfied, need information.

All these will flock together, revealing seams - but only if you are willing to take various perspectives.

Actively.

Consciously.

Happy contextualizing!