Screaming Architecture
Arquitectura que "grita" el Dominio
En esta arquitectura, la estructura del proyecto refleja el dominio del problema, no los detalles técnicos. Los nombres de carpetas y archivos están orientados al negocio, facilitando la comprensión del sistema.
1. Estructura típica #
src/
├── domain/ # Entidades y lógica de dominio
│ ├── user/
│ │ ├── User.js
│ │ ├── userService.js
│ │ ├── userRepository.js
│ │ └── userController.js
│ ├── product/
│ ├── Product.js
│ ├── productService.js
│ ├── productRepository.js
│ └── productController.js
│
├── shared/ # Recursos compartidos
│ ├── utils/
│ │ ├── logger.js
│ │ └── errorHandler.js
│ └── config/
│ ├── database.js
│ └── environment.js
│
└── index.js # Punto de entrada
2. Ventajas de Screaming Architecture #
- Centrada en el Dominio:
- Los desarrolladores entienden rápidamente qué hace la aplicación.
- Escalabilidad:
- Es fácil agregar nuevos módulos de dominio sin reorganizar la estructura.
- Reducción de Complejidad:
- Los detalles técnicos se encapsulan dentro de cada dominio.
Resumen del tema
Conceptos clave #
- Screaming Architecture: la estructura de directorios debe "gritar" de qué trata el negocio (ej.
orders,billing,users) en lugar de mostrar únicamente herramientas técnicas o frameworks (controllers,views). - Empaquetado por Componente / Dominio (Package by Feature): reúne en una misma carpeta todo lo necesario para una funcionalidad (entidad, servicio, repositorio, controlador).
- Autodescripción: facilita que los recién llegados comprendan el propósito del sistema simplemente observando la raíz de la carpeta
src/.
Qué debes recordar #
Organiza las carpetas por casos de uso y módulos de negocio para que la arquitectura comunique el propósito real de la aplicación.