gold ג ז י

When we talk about software patterns, we spend most of our time discussing the _technical_ contexts they make sense in. Building an API? Use the gateway pattern! Extracting functionality from a monolith? Use the strangler pattern! Etc etc etc.

In addition to its technical contexts, though, every pattern also has a set of _organizational_ contexts that it makes sense in - and these are usually implicit in our discussions.

But these organizational contexts are what separate use from overuse, when it comes to patterns. Ever work on a project where it felt like the team used the Gang of Four book like a checklist? That’s a team that misunderstood the appropriate organizational context for patterns.

Misjudging the appropriate organizational context for a pattern can be a lot more subtle, though. For example - no startup with all the engineers working together ever needs microservices.

For the same reason, no small company should be using web components. They exist to solve big company organizational problems.

The same patterns apply, whether we’re talking about object-oriented design, service architectures, container orchestration, or refactoring entire systems. Technical contexts are fractal. But the _organizational_ contexts are different at every level of detail.

My ears have perked up. Is there any reason not to write things in a limited surface area message-passing way? (You know, like microservices without the orchestration, discovery or networking complexity.)