Let Me Hear you Scream(ing Architecture)
The software architecture should scream the intent of the system. — Uncle Bob
Let me hear you scream like you want it Let me hear you yell like you mean it
This is a part of the refrain from Ozzy Osbourne’s song “Let Me Hear You Scream.” Let me modify it a little bit into a software-related context.
Let me hear it screams like client want it Let me hear it yells like client mean it
Otherwise, let your software architecture copy the intent of an application. The purpose of the application is mostly what the client wants. This is the ceiling of my creativity. Enjoy it. It will not get any better.
Screaming Architecture
The author of the term Screaming Architecture is Robert C. Martin. He is presenting it in the blog post from 2011. Uncle Bob pointed out that every architectural blueprint is telling you the building’s intent.
From family residences to the library, the reader of such a blueprint can quickly recognize the building’s purpose. Blueprints screams building’s use-cases and software architecture should work the same way. You can read how to centralize your software architecture around application use-cases in my older post.
What is Software’s Blueprint
A blueprint is a reproduction of a technical drawing or engineering drawing using a contact print process on light-sensitive sheets — Wikipedia
The technical drawing of software is mostly done at the beginning of every project. But such drawings are more abstractions than a precise, detailed description of an application.
Every time you want to find out the application functionality’s precise details, you are going through the source code and read it from it. It follows that the software’s blueprint is its codebase.
Software architecture can scream its intent as soon as its codebase structure is organized around the use-cases.
Functional Organization
Mostly, We are organizing the codebase around patterns and principles — Categorical Organization. Once we know how `Controller looks, we don’t help in the form of the parent directory’s name to identify it.
We can organize our folder structures and namespaces according to the high-level use case of the system; concepts pertain to the user’s interactions with objects in the system — Functional Organization.
You might already use the Functional Organization of folders in the Data Access Layer. It is very common to structure entities according to its module, and the module is the same concept of abstraction as a high-level use-case. You can find more about layers in my article here.
Pros
- Spatial locality — things which are supposed to be together, lived together.
- Easy to navigate
- Domain-Driven Design friendly
Cons
- Loose of framework conventions.
- Loose of automatic scaffolding feature.
- Categorical is easier for green-field projects.
Summary
Architecture should scream its intent but also follow important principles. Your work as a software architect is to find the best possible balance between them.
I am using Function Organization in my codebases, but only for the business part of an application.
- In Domain-centric Architecture in Domain and Application Layers.
- In Database-centric Three-layered Architecture in Business Layer.
I like more Categorical Organization in Presentation Layers because I am more backend developer, and Categorical Organization is more junior programmer-friendly.
Sources Pluralsight course — Clean Architecture: Patterns, Practices, and Principles by Matthew Renze Robert C. Martin’s blog post from 2011 — Screaming Architecture. Blueprint on Wikipedia.
