De las capas a las funciones: ¿Por qué nació Vertical Slice? (DE Las Capas A Las Funciones Por Que Nacio Vertical Slice)

No culpemos primero a CRUD y a las capas

La arquitectura en capas es un buen comienzo para muchos sistemas pequeños y medianos. Separación de controlador, servicio de aplicación, repositorio y acceso a datos; Le da al equipo un lenguaje técnico común. El problema no es la existencia de estas capas. El problema es que una única solicitud de usuario se extiende con el tiempo a todas las capas y cada cambio se convierte en una tarea de coordinación.

Un día llega una petición aparentemente sencilla: añadir un albarán de entrega al pedido.```text Controller → Request / DTO → Service → Validator → Repository → Mapping → Test doubles → Tests

## Conceptos en la primera mención```text
📦 Vertical Slice
Bir kullanıcı niyetini request'ten veri kaydına ve teste kadar tek sınırda tutan uçtan uca özellik birimi.

📦 Davranışın yerelliği
Bir davranışı anlamak veya değiştirmek için gereken kodun birbirine fiziksel olarak yakın olması.

📦 Temporal DRY
Bugün benzer görünen kodun, yarın aynı sebeple değişip değişmeyeceğini sorgulayan DRY yaklaşımı.

📦 Wrong abstraction
Sadece tekrar var diye erken paylaşılan; zamanla farklı ihtiyaçları birbirine bağlayan soyutlama.
```Vertical Slice no prohíbe las capas. Mantiene la distinción técnica dentro de la característica; El límite exterior de la función está determinado por la intención del usuario, las reglas comerciales y la propiedad.

## Story: when do layers slow down?

El primer día `CreateOrder` es más pequeño. Un controlador, un servicio y un repositorio parecen suficientes. Luego se agrega el control de stock, regla de campaña, preferencia de entrega y registro de auditoría. Cuando cada atributo cae en el mismo `OrderService`, el archivo más riesgoso del sistema se convierte en el archivo más utilizado.```text
Yeni özellik
  → ortak Service'e dokunur
  → ilgisiz testleri etkiler
  → farklı ekiplerin release'ini bekler
```CRUD no está roto. La responsabilidad del modelo y la capa de aplicación varía. La pregunta de Vertical Slice es: ¿Qué intención comercial está cambiando este comportamiento?

## Organización horizontal y vertical

| Criterio | Centrado en capas | Centrado en funciones |
| --- | --- | --- |
| Eje organizacional | Rol técnico | Intención/característica del usuario |
| Unidad de cambio | Archivo en múltiples capas | Límite de función única |
| Compartir código | Tendencia temprana de servicios comunes | Asociación probada |
| Navegación | Controlador → servicio → repositorio | Característica → solicitud → controlador → prueba |
| Efecto de error | Puede propagarse a través de una capa común | Característica sigue siendo más visible en su borde |```text
❌ Controllers / Services / Repositories
    → OrdersController
    → OrderService
    → OrderRepository

✓ Features / Orders / CreateOrder
    → Request
    → Validator
    → Handler
    → Response
    → Tests
```Esta diferencia no es sólo el nombre de la carpeta. Afecta el costo de encontrar, comprender, probar y revertir un cambio. Incluso si el costo de buscar dentro de una característica sigue siendo O(n) en el peor de los casos para la cantidad de archivos `n`, la colocación de código relacionado reduce la búsqueda en directorios incorrectos y la cantidad de cambios mentales.

## Screaming Architecture: ¿qué debería decir la estructura del directorio?

Si las primeras carpetas que aparecen al abrir un proyecto son `Controllers`, `Services` y `Infrastructure`; Explica las herramientas técnicas del sistema. `Orders`, `Catalog`, `Billing` y `Returns` describen el campo comercial. Debería gritar la intención del producto, no el marco arquitectónico.

En un cambio `CancelOrder`, el desarrollador encuentra el controlador, la verificación, la respuesta y las pruebas del comportamiento en un mismo lugar; También acorta la curva de aprendizaje de un nuevo miembro del equipo. Sin embargo, la carpeta de funciones no es un pequeño monolito donde todo es público. El punto de entrada permanece abierto; Los detalles están ocultos en la función.

## Cohesión, encapsulación y duplicación estratégica

Un Slice no debe conocer la implementación interna de otro Slice. El comportamiento conjunto debe ser compartido si es verdaderamente estable y cambia por la misma razón al menos por varias necesidades independientes. De lo contrario, la carpeta `Shared` se convierte en una nueva capa sin bordes visibles.```text
CreateOrder
  → Order aggregate'e komut verir
  → local transaction'ı tamamlar
  → response üretir

CancelOrder
  → kendi kurallarını uygular
  → CreateOrder'ın handler'ını çağırmaz
```En este enfoque, la duplicación es a veces el precio correcto. Si dos fragmentos de código similares van a cambiar debido a diferentes decisiones comerciales, fusionarlos temprano puede propagar cada cambio a características dependientes de O(k) en el futuro.

## Señales de transición

Tener un aspecto moderno no es suficiente para cambiar a Vertical Slice. La inversión regresa cuando las siguientes señales ocurren juntas:

1. Cuando una solicitud simple requiere constantemente cambios en muchas capas.
2. Pequeños cambios en servicios comunes interrumpen las pruebas de funciones no relacionadas.
3. Si las pruebas simuladas intensivas preservan el comportamiento pero no el orden de llamada interna.
4. Si el equipo tiene problemas para determinar en qué archivo se encuentra una regla comercial.
5. Si se separan los propietarios y ritmos de entrega de distintas características.

Estos límites no deben quedar con la documentación. Con las pruebas de arquitectura en .NET, puede comprobar que una característica no depende de los detalles internos de otra característica. El costo de la regla es el escaneo O (dependencia) durante la fase de compilación o prueba; El beneficio es que la infracción aparece antes de llegar a producción.

## DDD y su relación con CQRS

Vertical Slice organiza la aplicación. DDD describe dónde residen las reglas comerciales y el lenguaje. CQRS, por otro lado, puede separar el flujo en los lados de comando y consulta de un caso de uso. Estos no son competidores, sino diferentes niveles de decisiones.```text
Feature boundary  → Vertical Slice
Consistency rule  → DDD Aggregate
Read / write flow → CQRS
Deployment unit   → Modular monolith veya microservice
```Validar primero el límite de la característica dentro del monolito modular permite probar la afirmación de independencia sin pagar el costo del microservicio por adelantado.

## Coincidencias que crean falsa confianza```text
❌ Vertical Slice = klasörleri yeniden adlandırmak
✓ Kullanıcı niyeti, davranış ve sahipliği aynı sınırda tutmaktır.

❌ DRY = her benzer kodu paylaşmak
✓ Aynı nedenle değişen kodu paylaşmaktır.

❌ Handler = tüm iş kuralları
✓ Handler orkestrasyon yapar; domain kuralları uygun domain modelinde yaşar.

❌ Vertical Slice = mikroservis
✓ Önce modüler monolith içinde doğrulanabilen application boundary'dir.

❌ Shared = ücretsiz yeniden kullanım
✓ Shared, sürümleme ve koordinasyon maliyeti de getirir.

Lista de verificación de decisiones

1. ¿Este código cambia debido a la misma intención del usuario?
2. ¿Pueden coexistir la solicitud, la validación, el controlador, la respuesta y las pruebas de una característica?
3. ¿Puedo satisfacer mis necesidades sin acceder a la clase interna de otra característica?
4. ¿Esta abstracción común cambia por la misma razón en al menos tres lugares independientes?
5. ¿Están separadas la orquestación de aplicaciones y reglas agregadas?
6. ¿El límite de la característica está protegido por pruebas arquitectónicas dentro del monolito modular?
7. ¿Son visibles el impacto del error, la cobertura de la prueba y la ruta de reversión después del cambio?

El objetivo no es producir más carpetas. El objetivo es reducir la superficie de decisión y código necesaria para cambiar un comportamiento.

Lo que debes recordar de este artículo

1. La arquitectura en capas no es mala; Sin embargo, cuando la unidad de intercambio se dispersa entre capas, el costo de coordinación aumenta.
2. Vertical Slice centra el código en la intención y el comportamiento del usuario en lugar de en roles técnicos.
3. La duplicación estratégica puede ser más barata que la falsa abstracción.
4. Rebanada vertical; DDD es una decisión de organización de aplicaciones que funciona en conjunto con CQRS y monolito modular.

El propósito de Vertical Slice no es organizar archivos verticalmente; es mantener el efecto del cambio en el límite de características correcto.

En la siguiente sección, examinaremos cómo funciona un Slice desde adentro con solicitudes, validación, controlador, mapeo y pruebas.