Arquitectura expresiva e intención de los casos de uso
Aprenda por qué una arquitectura limpia debe revelar el dominio de la aplicación de un vistazo, no el framework que utiliza.
Arquitectura expresiva e intención de los casos de uso es una lección gratuita de Clean Architecture & Design Patterns in Practice en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Clean Architecture & Design Patterns in Practice, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Clean Architecture & Design Patterns in Practice incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en inglés.
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.javaThe 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.
Preguntas frecuentes
¿La lección «Arquitectura expresiva e intención de los casos de uso» es gratis?
Sí — el texto completo de «Arquitectura expresiva e intención de los casos de uso» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Clean Architecture & Design Patterns in Practice, actualiza a CoddyKit PRO. El curso de Clean Architecture & Design Patterns in Practice incluye 4 lecciones en total.
¿Qué aprenderé en «Arquitectura expresiva e intención de los casos de uso»?
Aprenda por qué una arquitectura limpia debe revelar el dominio de la aplicación de un vistazo, no el framework que utiliza. Practicas Clean Architecture & Design Patterns in Practice con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Clean Architecture & Design Patterns in Practice?
No se requiere experiencia previa. Clean Architecture & Design Patterns in Practice en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Arquitectura expresiva e intención de los casos de uso»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Clean Architecture & Design Patterns in Practice?
Sí. Cada lección de Clean Architecture & Design Patterns in Practice incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- ¿Qué es la Arquitectura Limpia?
- Comprender las capas arquitectónicas
- La regla de dependencias explicada
- Arquitectura expresiva e intención de los casos de uso