Screaming Architecture: Architectures that shout out their purpose

Introduction

How many times have you opened a project and thought: Laravel, Symfony, Django, Rails, NestJS, WordPress...? And on the other hand, how many times have you opened a project and thought: podcast application, ticketing system, rental platform, social network...?

It is quite common in our world to get carried away by the decisions made by others, and by others I mean the developers of the framework we are using. We start a project with a framework and we directly get carried away by the directory structure and architecture decisions that best suited the team that developed the framework, instead of focusing on what our project needs in order to shout its purpose.

Screaming Architectures

In 2011, Bob Martin proposed the concept of screaming architecturearchitectures that shout to the four winds their purpose, the project they are modeling.

The easiest simile to understand is that of an architect's plans: at a glance, it is clear whether the design corresponds to a house, an airport, a square, a shopping center, etc. At no time is there any mention of materials. Not yet, those details will come later. The goal is to define a design that meets the project specification: a welcoming home, an efficient airport, a square with shadows and benches, a shopping mall accessible to everyone...

In the development field, a good architecture should meet these same objectives, adjusting to the system being modeled, regardless of whether the database is MySQL or MongoDB, whether we will use Laravel o Symfony, whether we will use ORMs based on DataMapper or ActiveRecord. Our architecture must be able to be tested without having made these decisions yet.

The framework is just another tool

What this leads us to is that we should consider the framework we have chosen as one more external dependency, not the basis on which to build our domain. We should not make crucial decisions based on the features or functionalities of the framework we have chosen, since we will be tying ourselves to it.

It may be tempting, and it has happened to all of us, but there is certainly a world of advantages when we take control of our domain, and it protects us against unexpected setbacks: third-party dependencies that are abandoned or not updated, design twists that affect us in such a way that we cannot continue working unless we invest time in upgrading to the new design... etc.

But not everything is to propose to disengage from the framework of the moment, we have to know how to choose our tools well, since many frameworks only work well if you follow their rules and you couple to it, and then it is up to us to know whether to get into this mess, or simply get carried away, either by the duration of the project, by the growth expectations or simply because it is an MVP that we will discard as soon as we validate our business.

If you choose to decouple, be well informed about your options. Frameworks that define themselves as opinionated often set a rigid way of working from which it is difficult to escape if we want to continue getting the most out of it, and it is often better to opt for microframeworks that we can expand with other third-party libraries or with our own.

A good way to detect whether it will be complicated or not to disengage from the framework, is to detect which is its main component. If it is an ORM, it will probably be difficult to abstract from it, since by design it forces us to use a database, but if its main component is a dependency container, be sure that it will be easy, since it is giving you the main tool to achieve this decoupling.

Conclusions

Screaming architecture is more a concept than an architecture in itself. The only rule it must comply with is shout out its purpose, do not cede control to a framework, CMS or a library that monopolizes the limelight and pushes down our business domain.

It is not a simple task. It's not always going to be feasible. It's not always going to be profitable. Is it a bad idea? Not at all. In my experience having been able to work on projects using this approach, I have seen that the onboarding and adaptation times for new developers is much less, in comparison.

Sometimes friction arises when a developer from the chosen framework joins the project and things are not done as he is used to doing, but his understanding of the domain is much greater in less time, and learning a new workflow is something we do every few years.

On the other hand, this control over the workflow gives us extra independence when it comes to making relevant decisions in the design of our project and the possibility of modifying it according to our needs.

On the other hand, if the project you face has a finite duration, without the possibility of expanding or growing, or adding more developers, do not hesitate to use the tools you consider to deliver on time, coupling and taking full advantage of them.