Software Architect · Módulo 06
Las capas se ganan su lugar cuando protegen la lógica importante de los detalles: HTTP, bases de datos, colas, SDKs y el framework de turno.
Clean Architecture · dependency inversion · ports and adapters
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.
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.
- ¿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?