0Pricing
Clean Architecture & Design Patterns in Practice · Lesson

Screaming Architecture and Use-Case Intent

Learn why a clean architecture should reveal the application domain at a glance, not the framework it happens to use.

Screaming Architecture and Use-Case Intent is a free Clean Architecture & Design Patterns in Practice lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Clean Architecture & Design Patterns in Practice learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What Does Your Structure Say?

Open a typical project and you often see folders named controllers, models, views. That structure shouts the framework, not the purpose.

Robert C. Martin called the alternative Screaming Architecture: the top-level structure should scream what the system does.

Architecture Is About Intent

Just as a building plan screams library or hospital, a healthcare app should scream patient scheduling and billing — not Spring or React.

The use cases are the heart of the system, so they should be the most visible thing.

Framework-Centric Structure

A framework-driven layout buries the domain.

src/
  controllers/
  repositories/
  entities/
  config/

Intent-Revealing Structure

A use-case-driven layout puts the domain first.

src/
  scheduling/
  billing/
  patient_records/
  prescriptions/

Frameworks Are Details

This reinforces a core Clean Architecture idea: the framework is a delivery mechanism, a detail you plug in.

Your business rules should not depend on whether you chose one web framework over another. The structure should make that independence obvious.

Deferring Decisions

When the domain leads the structure, you can defer infrastructure choices.

You can begin building and even testing core use cases before committing to a database or web framework, because those live at the edges.

Testability Reveals Intent

A telltale sign of screaming architecture: you can test all your use cases without the framework, the UI, or the database running.

If your tests need a web server to verify a business rule, the framework has leaked into the core.

Mapping Use Cases to Modules

Each major use case or feature becomes a clearly named module or package. Inside it live the entities and interactors that implement that capability.

scheduling/
  ScheduleAppointment.java
  CancelAppointment.java
  Appointment.java

The Plugin Mindset

Think of the web, the database, and external services as plugins to your application core.

The core defines the rules; the plugins adapt the outside world to those rules. This mindset directly produces screaming structure.

Common Pushback

Teams sometimes resist because frameworks ship with conventional folder layouts.

You can still honor those conventions at the edges while organizing your core by domain. The goal is that the most important code is the most visible.

A Quick Self-Test

  • Can a newcomer guess what the app does from the folder names?
  • Can you delay choosing a database?
  • Can use cases be tested without the framework?

Three yeses mean your architecture is screaming the right thing.

Quick Check

Test your understanding of screaming architecture.

Recap

You learned that a clean structure should scream its domain.

  • Organize by use case, not by framework role.
  • Frameworks and databases are deferrable details.
  • If use cases test without the framework, intent leads the design.

Frequently asked questions

Is the “Screaming Architecture and Use-Case Intent” lesson free?

Yes — the full text of “Screaming Architecture and Use-Case Intent” is free to read here on the web, and the Clean Architecture & Design Patterns in Practice course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Clean Architecture & Design Patterns in Practice course, upgrade to CoddyKit PRO.

What will I learn in “Screaming Architecture and Use-Case Intent”?

Learn why a clean architecture should reveal the application domain at a glance, not the framework it happens to use. You practise Clean Architecture & Design Patterns in Practice with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Clean Architecture & Design Patterns in Practice?

No prior experience is required. Clean Architecture & Design Patterns in Practice on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Screaming Architecture and Use-Case Intent” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Clean Architecture & Design Patterns in Practice lesson?

Yes. Every Clean Architecture & Design Patterns in Practice lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. What is Clean Architecture?
  2. Understanding Architectural Layers
  3. The Dependency Rule Explained
  4. Screaming Architecture and Use-Case Intent
← Back to Clean Architecture & Design Patterns in Practice