The Screaming Architecture Story

4 min readNov 12, 2023

What exactly is Screaming architecture?
Architecture in software should discuss the domain behind the system rather than implementation specifics.

Consider yourself to be looking at a building’s plans. This document, written by an architect, describes the building’s plans. What do these plans indicate?

Single-Family Home Design:

Front entry
Foyer leading to a living room
Possibly a dining room
Kitchen nearby, close to the dining room
Diner space next to the kitchen
Family room nearby
Clear indication of a house in the plans

Library Architecture:

Magnificent entrance
Area for check-in-out clerks
Reading places
Modest conference rooms
Galleries capable of storing numerous bookcases
Distinctive features immediately convey a “Library!” identity

So, what does your application’s architecture say? Do the top-level directory structure and the source files in the highest-level package scream Health Care System, Accounting System, or Inventory Management System? Or are they yelling Rails, Spring/Hibernate, or ASP? For example

An Architecture’s Theme

In “Object-Oriented Software Engineering,” Ivar Jacobson emphasizes a method based on use cases for software architecture. The book underscores that software architectures should inherently support the system’s use cases, akin to how the plans for a house or a library clearly express the purposes of those buildings.

Key Points:

Use-Case-Centric Architecture:

Software architectures should revolve around and support the system’s use cases.
The architecture should vividly represent the intended functionality of the application.

2. Frameworks and Architectures:

Frameworks should not be the primary focus of architectures.
Architectures should not be dictated by frameworks; instead, frameworks should be tools used within architectures.

3. Frameworks vs. Use Cases:

Building architecture solely on frameworks may undermine the alignment with use cases.
The emphasis is on using frameworks as tools rather than shaping architectures around them.

The Function of Architecture

In creating good architectures, the focus should be on use cases, allowing architects to define structures that support these cases without committing prematurely to specific frameworks, tools, or environments. Drawing a parallel to house plans, the priority is ensuring the usability of the house, not fixating on the materials. The architect ensures flexibility for the homeowner to choose materials later, once the use cases are addressed.

Key Points:

Use-Case-Centric Approach:

Good software architectures prioritize use cases as the central focus.
Architects describe structures supporting use cases before committing to frameworks or tools.

2. Deferring Technical Decisions:

A good architecture enables the postponement of decisions regarding frameworks, databases, web servers, etc.
Specific technologies like Rails, Spring, Hibernate, etc., can be decided later in the project.

3. Flexibility and Easy Changes:

Good architectures allow for flexibility in changing decisions about frameworks and tools.
Decoupling use cases from peripheral concerns facilitates adaptability throughout the project.

But what about the Web?

The web or internet is not inherently an architecture; it serves as a delivery mechanism. The mode of delivery, whether via the web or another means, should not dictate the overall system architecture. It is emphasized that the fact your application is delivered over the internet is a minor detail and should not dominate the system architecture. The recommendation is to defer considerations about the delivery mechanism, ensuring that the system architecture remains agnostic to how it will be delivered. This approach enables flexibility, allowing the application to be delivered as a console app, web app, thick client app, or web service app with minimal code changes or difficulty.

Frameworks are tools, not lifestyles.

Frameworks, while powerful, often come with a strong endorsement from their authors and users. Authors and proponents typically showcase examples with an all-encompassing, let-the-framework-do-everything attitude. The advice given is to approach frameworks critically and with skepticism. It is important to assess their benefits and understand potential costs. Questions should be asked about how to use a framework, how to defend against it, and most importantly, how to maintain the emphasis on the use-case-driven architecture without allowing the framework to dominate it. The key is to carefully evaluate frameworks and ensure they align with the architectural priorities of the system.

Architectures that can be tested

If your system architecture is all about use cases and you’ve kept your frameworks at bay. Then you should be able to unit-test all of those use cases without using any frameworks. Your tests should not require the web server to be running. You shouldn’t need to connect to the database to run your tests. Your business objects should be simple objects that do not rely on frameworks, databases, or other complexities. Your use case objects and business objects should be coordinated. And all of them should be testable in place, without the complications of frameworks.

Conclusion

Your architectures should inform readers about the system, not the frameworks you used. When new programmers look at the source repository for a healthcare system, their first thought should be, “Oh, this is a healthcare system.” Those new programmers should be able to learn all of the system’s use cases while remaining unaware of how the system is delivered. They may approach you and say, “We see some things that look like models, but where are the views and controllers?” To which you should respond, “Oh, those are details that don’t need to concern you right now; we’ll show them to you later.”

For Reference

This article has taken some references from the original article published here https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html Some other references: https://www.linkedin.com/posts/danielmoka_if-you-look-at-your-application-and-you-only-activity-7125014766686793728-Qp1X/?utm_source=share&utm_medium=member_android