# 06. Capas y dependencias Cómo orientar las dependencias hacia la lógica de negocio, dónde se ganan su lugar los ports and adapters y por qué el framework no debería convertirse en la arquitectura. - **Author:** Fedor Chishchin - **Level:** advanced - **Reading time:** ~25 minutos de lectura - **Published:** 2026-05-23 - **Source:** https://fedorthinks.com/es/learn/software-architect-06-layers --- ## 1. La idea central Las reglas de negocio tienen que depender del lenguaje del dominio, no de cómo se entregó la request. ### Los detalles van afuera > Los cimientos de una casa no pueden depender del color de las cortinas. Las cortinas las cambiás. Los cimientos, casi nunca. Clean Architecture, Hexagonal Architecture y Onion Architecture describen una sola idea: el centro del sistema contiene las reglas del dominio y los use cases, y las capas externas contienen los detalles. El REST controller, la SQL query, el Redis cache, el Stripe SDK, el message broker — detalles importantes, pero no la fuente de las reglas de negocio. El **Dependency Inversion Principle** mantiene las flechas apuntando para el lado correcto: la política de alto nivel depende de abstracciones, y las implementaciones se enchufan desde afuera. En la práctica eso se ve como un port `PaymentGateway` y un adapter `StripePaymentGateway`. ### Una capa tiene que hacer trabajo > Un pasillo vacío entre dos cuartos es útil si la gente lo cruza. Si sólo agrega distancia, es metros cuadrados desperdiciados. Una capa se justifica cuando aporta isolation, testability o un ritmo de cambio propio. El application layer coordina un use case. El domain layer guarda las reglas y los invariantes. El infrastructure layer habla con el mundo de afuera. Una capa que se limita a mover parámetros de un método a otro no es arquitectura — es ceremony. El arquitecto tiene que defender al sistema de las dos cosas: boundaries que faltan y multicapa sin sentido. ## 2. Ejemplo y antiejemplo La testability te muestra rápido si las dependencias apuntan para el lado correcto. ### Ejemplo: crear una orden sin base en un unit test > Para probar una receta no hace falta abrir el restaurante. Alcanza con una cocina y los ingredientes. El use case `CreateOrder` recibe `InventoryPort`, `PaymentPort` y `OrderRepository` como dependencias. En el unit test se reemplazan por fakes. El test chequea una regla: no se puede crear una orden sin un precio fijado y sin un payment intent exitoso. Ni la base de datos ni HTTP participan de ese test. Eso significa que la regla de negocio está separada de la infraestructura. ### Antiejemplo: Active Record como centro del universo > Si toda la lógica vive en la caja de herramientas, cada reparación arranca buscando el destornillador correcto. El modelo del ORM valida reglas de negocio, hace llamadas de red, manda mails, escribe el audit log y decide permissions. Parece cómodo mientras el sistema es chico. Después cada test levanta una base, cada cambio arrastra side effects y el dominio se vuelve imposible de reutilizar. El problema no es el ORM como tal. El problema es que el modelo de infraestructura terminó siendo el owner de la business policy. #### Autoevaluación - ¿Se puede verificar la regla principal sin base ni HTTP? - ¿Qué dependencias fluyen hacia adentro y cuáles hacia afuera? - ¿Dónde es el framework el que dicta el modelo de dominio? - ¿Qué adapters se pueden reemplazar sin tocar el use case? Próximo módulo: [APIs y contratos](./software-architect-07-api-contracts).