Arquitectura que Grita

Robert Martin acuñó el término "Arquitectura que Grita" a partir de una observación simple: cuando miras los planos de una biblioteca, la estructura grita "Biblioteca". Un plano de hospital grita "Hospital". Pero cuando miras la mayoría de los proyectos de software, la estructura de nivel superior grita "Rails", "Spring" o "Django" — no el negocio al que sirve.

Si tus directorios de nivel superior son controllers/, models/ y views/, estás mirando una aplicación MVC. No puedes saber por los nombres de las carpetas si gestiona pacientes, pedidos, facturas o transbordadores espaciales. El framework ha robado la identidad del proyecto.

La buena arquitectura hace el dominio visible. Los nombres de las carpetas deben leerse como una conversación con un experto del dominio: billing/, patients/, appointments/. Los frameworks son herramientas — deben vivir en los bordes, no en la cima. Una buena arquitectura te permite diferir la decisión del framework y mantenerlo reemplazable.

A top-level folder structure that reveals the framework, not the business — a new developer cannot tell what the system does without reading the code.

# Top-level structure screams "MVC framework", not "e-commerce"
# models/user.py
# models/order.py
# views/user_views.py
# controllers/order_controller.py

# A new developer sees: "This is an MVC app."
# They cannot tell what the business does from folder names alone.
# Is it e-commerce? Healthcare? Logistics? Impossible to know.
# The framework owns the structure — the domain is invisible.

// Top-level structure screams "Express app", not "healthcare system"
// controllers/
//   appointmentController.ts
//   patientController.ts
// models/
//   appointment.model.ts
//   patient.model.ts
// routes/
//   appointments.ts
//   patients.ts

// A new developer sees: "This is an Express app."
// The framework's naming conventions have colonized the architecture.

Organize by bounded context — each top-level folder is a business domain. The framework lives in infrastructure/ at the edge and can be swapped without touching domain code.

# Top-level: "e-commerce system"
# catalog/          — products, categories, search
# ordering/         — cart, checkout, order lifecycle
# payments/         — payment methods, billing, invoices
# shipping/         — fulfillment, tracking, carriers
# infrastructure/   — framework wiring, DB adapters, HTTP controllers

# A new developer sees: "This is an e-commerce system."
# The framework (Django, FastAPI, Flask) lives in infrastructure/.
# If you swap frameworks, only infrastructure/ changes.
# Business logic in catalog/, ordering/, payments/ is untouched.

// Top-level: "healthcare system"
// patients/
//   Patient.ts               — domain entity
//   PatientRepository.ts     — abstract interface
// appointments/
//   Appointment.ts
//   ScheduleAppointmentUseCase.ts
// billing/
//   Invoice.ts
//   GenerateInvoiceUseCase.ts
// infrastructure/
//   express/                 — HTTP adapters, route wiring
//   postgres/                — repository implementations

// A new developer sees: "This is a healthcare system."
// Express lives only in infrastructure/express — replaceable without
// touching any business logic.