iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Clean Architecture y Vertical Slice Architecture responden a preguntas distintas, así que no compiten entre sí. Clean Architecture define límites y la dirección de las dependencias para que las reglas de negocio no dependan de la base de datos, del framework web ni de otros detalles de infraestructura. Vertical Slice Architecture organiza el código alrededor de una funcionalidad, de modo que los archivos que cambian juntos vivan juntos. El cansancio que describen muchos equipos suele venir de recorrer capas y proyectos para cambios pequeños cuando las fronteras no protegen nada relevante. Es un problema de ajuste entre estructura y necesidad, no un defecto que el patrón traiga siempre.
Dos preguntas distintas
Clean Architecture: qué depende de qué
Microsoft Learn presenta Clean Architecture como una familia de estilos emparentada con Hexagonal Architecture, Ports-and-Adapters y Onion Architecture. El núcleo de la aplicación contiene el modelo y la lógica de negocio. Las abstracciones para acceder a datos, archivos o redes viven en ese núcleo, y la infraestructura aporta las implementaciones. La interfaz de usuario depende de interfaces definidas dentro del núcleo, y la inyección de dependencias conecta las implementaciones en tiempo de ejecución.
Vertical Slice Architecture: qué está junto
Vertical Slice Architecture responde a otra pregunta: dónde está todo lo necesario para cambiar una funcionalidad. En lugar de agrupar el código en carpetas globales como Controllers, Views o ViewModels, los archivos de una feature quedan juntos. La guía de ASP.NET Core de la documentación de dotnet/docs describe, para APIs, que las carpetas pueden reemplazar a los controllers y contener endpoints y DTOs relacionados.
Recommended Free Tools
Por eso no son doctrinas excluyentes. Un slice puede llamar a reglas de dominio compartidas y apoyarse en abstracciones de infraestructura cuando estas protejan algo real.
#1 Best Overall
Comparación en cinco ejes
| Eje | Clean Architecture | Vertical Slice Architecture | Pregunta para el equipo |
|---|---|---|---|
| Organización principal | Capas o proyectos con responsabilidades separadas | Features o casos de uso | ¿Dónde busca el equipo cuando cambia una feature? |
| Frontera que protege | El núcleo de negocio frente a detalles de infraestructura | La coherencia de una capacidad funcional completa | ¿Qué frontera reduce más fricción en este proyecto? |
| Dependencias | Reglas explícitas hacia el núcleo y abstracciones definidas en él | Se decide dentro de cada slice, respetando los límites que sí se necesiten | ¿Qué reglas no deberían depender de EF Core, HTTP u otros detalles? |
| Coste estructural | Más proyectos, contratos y composición que mantener | Menos capas que navegar; a cambio, cierta duplicación si se comparte poco | ¿Qué duplicación es más barata que una abstracción central prematura? |
| Pruebas | El núcleo se puede probar aislado; la infraestructura necesita pruebas con sus dependencias externas | Las pruebas por comportamiento de cada caso de uso encajan de forma natural; las fuentes no cuantifican una ventaja | ¿Qué nivel de prueba protege mejor el caso de uso y el dominio? |
| Mejor encaje | Dominios con reglas importantes, cambios de infraestructura previstos o límites de equipo claros | Features que cambian de forma independiente y proyectos donde navegar por capas globales resulta costoso | ¿Qué complejidad existe hoy, no cuál podría aparecer más adelante? |
Las celdas sobre organización y aislamiento se basan en la documentación de Microsoft Learn y dotnet/docs. Las preguntas de la última columna son criterios de decisión, no resultados de un experimento comparativo.
De dónde viene el cansancio
El cansancio no es una métrica en las fuentes revisadas, pero sí se pueden identificar mecanismos concretos que lo producen:
Rank #2
- Navegación. Cambiar una feature obliga a abrir Application, Domain, Infrastructure y Web. La documentación de dotnet/docs señala que la organización por tipo de archivo puede obligar a saltar entre carpetas para localizar lo relacionado con una misma funcionalidad.
- Ceremonia. Interfaces, DTOs y mapeos que no protegen ninguna regla cuando el caso de uso es un CRUD directo.
- Composición. Registrar servicios e implementaciones en varios puntos del arranque de la aplicación.
- Coordinación en revisión. Un único caso de uso repartido entre varios archivos que hay que revisar, probar y mantener sincronizados.
- Procesos separados. Microsoft Learn advierte que separar servicios o procesos añade complejidad. Clean Architecture no obliga a desplegar microservicios, pero algunos equipos la asocian con ellos.
Estos mecanismos son observables en el código. Las fuentes revisadas no contienen un estudio cuantitativo que compare cansancio, velocidad o productividad entre ambos estilos, así que cualquier experiencia personal debe leerse como contexto y no como estadística.
Un mismo cambio, dos recorridos
Supongamos la regla «un pedido solo se puede cancelar antes de enviarse». Los nombres de carpetas y clases siguientes son ilustrativos; el número de archivos depende de cada diseño concreto y no es una medida general.
Rank #3
Con organización en capas
- En
Domain/Orders/Order.cs, añadir el métodoCancel()que valide el estado del pedido. - En
UseCases/Orders/, crear o modificar el caso de uso de cancelación y, si hace falta, la interfaz del repositorio definida en el núcleo. - En
Infrastructure/, ajustar la implementación del repositorio si cambia la consulta. - En
Web/, modificar el controller o endpoint que invoca al caso de uso. - Escribir una prueba unitaria del núcleo sin infraestructura y una prueba de integración del repositorio.
Con organización por slice
- En
Features/Orders/CancelOrder/, agrupar el request, el handler, la validación, el endpoint y el test de comportamiento. - Si la regla de estado es estable y se usa en otros lugares, mantenerla en el modelo de dominio; si solo la usa este caso de uso, dejarla dentro del slice.
- Ejecutar el test de comportamiento del slice.
La diferencia visible es el recorrido del cambio. La regla de negocio sigue existiendo en ambos casos, y en el enfoque por slice todavía hay que decidir dónde vive.
Cuándo las capas pagan su coste
Las fronteras de Clean Architecture compensan cuando el esfuerzo de separación protege algo que cambia o es costoso de equivocar:
Rank #4
- Invariantes de negocio importantes que deben cumplirse independientemente de cómo se llegue a ellas.
- Necesidad de probar el núcleo sin base de datos ni servidor web. Microsoft Learn lo expresa así: «Because the Application Core doesn’t depend on Infrastructure, it’s very easy to write automated unit tests for this layer». (Traducción propia: «Como el núcleo de la aplicación no depende de la infraestructura, es muy sencillo escribir pruebas unitarias automatizadas para esta capa».)
- Varias implementaciones de infraestructura o un cambio de proveedor previsto.
- Equipos con áreas de responsabilidad claramente separadas que necesitan contratos explícitos entre ellas.
Cuándo empezar por slices
Un enfoque por slice suele ser suficiente cuando el producto es pequeño, el dominio todavía no está claro y los cambios se concentran en funcionalidades concretas. Microsoft Learn ofrece un criterio útil para decidir: «If you can’t deliver independent feature slices of the application, separating it only adds complexity». (Traducción propia: «Si no puedes entregar slices de funcionalidad independientes de la aplicación, separarla solo añade complejidad».) Si cada cambio de negocio toca siempre las mismas capas, la separación por capas no está aislando nada que se pueda entregar por separado.
Plantillas de inicio en .NET
Ardalis documenta dos plantillas de inicio que reflejan esta diferencia:
| Plantilla | Estructura | Indicación según Ardalis | Evolución |
|---|---|---|---|
clean-arch |
Core, UseCases, Infrastructure y Web | Aplicaciones grandes o empresariales, mantenimiento prolongado, varios equipos y dominio complejo | Ya es la estructura completa por capas |
min-clean |
Proyecto único organizado por slices | MVPs, aplicaciones pequeñas, iteración rápida y equipos pequeños | Según la guía de Ardalis, puede migrarse a la plantilla completa al crecer |
Las versiones, dependencias e instrucciones de instalación cambian con el tiempo; compruébalas en la página Getting Started de Ardalis antes de empezar. La documentación de Microsoft sobre feature folders en ASP.NET Core usa ejemplos de distintas épocas del framework, así que adapta el código a la versión de .NET que utilices y no copies fragmentos antiguos como si fueran la API actual.
Qué puede afirmarse y qué no
- No existe, en las fuentes citadas, un estudio cuantitativo general sobre cansancio, velocidad de entrega o productividad comparando ambos estilos. Cualquier cifra que circule sobre ello debe verificarse en su origen.
- El ejemplo práctico de Daniel Balcarek, publicado el 13 de enero de 2026, compara dos APIs pequeñas e idénticas construidas con .NET Minimal APIs, implementando una operación Delete en cada una. El autor anuncia que compara velocidad de implementación, facilidad de pruebas unitarias y adición de features, pero declara que es una ilustración práctica limitada, no un análisis exhaustivo de ventajas y desventajas. Sirve como modelo de cómo diseñar una comparación, no como prueba de superioridad de ninguno de los dos estilos.
- Una comparación propia y reproducible debería usar el mismo caso de uso, el mismo comportamiento, las mismas pruebas y la misma persistencia en ambas estructuras, registrando los archivos tocados, los pasos de registro de dependencias y los cambios necesarios al añadir una nueva regla. Si la realizas, documenta el entorno y las versiones; este artículo no incluye resultados de esa prueba.
Un enfoque híbrido y evolutivo
En la práctica, la pregunta no es elegir una etiqueta, sino decidir qué frontera compra algo hoy. Un camino razonable es el siguiente:
- Organizar cada caso de uso como slice, con su endpoint, request, handler y validación juntos.
- Proteger con límites explícitos solo las reglas de dominio estables y costosas de equivocar.
- Mantener la infraestructura detrás de interfaces cuando haya una razón concreta: un proveedor distinto, pruebas que necesitan sustitución o una integración externa.
- Extraer código compartido cuando el patrón de cambio lo demuestre, no antes. Duplicar un poco suele salir más barato que una abstracción central prematura.
- Revisar la estructura cuando cambie el tamaño del equipo o aparezca una regla que cruce varios slices.
Diseñar para el problema actual, con límites donde protegen algo real, permite que la solución crezca cuando la evidencia del proyecto lo exija. Ninguna de las dos arquitecturas funciona como fórmula universal.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
