La tentación de la capitis

Cada que inicio un nuevo proyecto lo veo como una oportunidad para organizar diferente la estructura, la arquitectura, a fin de mejorar la forma en que se desarrolla el proyecto.

En esta etapa es fácil caer en la tentación de crear varias capas (capitis), con esto me refiero a la intención de separar toda la lógica o "responsabilidades" en proyectos separados. Intentar que el modelo del dominio del problema quede "puro", es decir, limpio de dependencias externas. Sin "manchas" con detalles de frameworks. Que alguien al abrir el proyecto vea nombres de carpetas que tengan que ver con el negocio, y no con detalles "sucios" como controllers, views, etc.

Es divertido definir la capa de negocio (o dominio) y estar programando abstracción, tras abstracción. Para después crear proyectos de implementaciones concretas usando cierta tecnología, librería o framework. Como no queremos tener implementaciones concretas, entonces definimos interfaces. Las cuales serán consumidas por la capa de presentación, claro que sin conocer las implementaciones concretas. Así será "fácil" cambiar (pensamos) de  implementación sin afectar la aplicación en un futuro.

Por poner un ejemplo (cuando se trabaja con .NET) se puede llegar a tener un proyecto "Negocio" que solo tiene clases que contienen el "core" del problema e interfaces para todo lo demás que necesita contener dependencias de terceros. Después se agrega un proyecto para cada tecnología que necesitas para realmente hacer las cosas, como "Negocio.EntityFramework" que es una implementación de nuestro proyecto usando EntityFramework para guardar los datos. Y nos sentimos bien porque en un futuro "podríamos" tener un proyecto "Negocio.FileSystem" que guarda los datos en disco directamente o una implementación que los guarde en MongoDB "Negocio.MongoDb". Esto por poner ejemplos. También podemos abstraer el Web como una presentación más y llegar a tener más interfaces e implementaciones concretas que podemos cambiar. Hay veces que se agrega una capa de "servicios" que lo único que haces es llamar a la capa de acceso a datos, incluso a veces es peor y llama a una capa de repositorios que entonces esa sí llama a la base da datos.

Lo que termina pasando, la mayoría de las veces que he visto esa arquitectura, es que solo se tiene una implementación para cada Interfaz. Es decir tantas abstracciones para nada. Solo es más código para ocultar la implementación concreta, al final esa abstracción contendrá fugas para así poder acceder a la funcionalidad que tiene la implementación concreta. A veces se usa el pretexto de que las pruebas serán más fáciles; pero la verdad es que en muchos de esos proyectos ni si quiera hay pruebas unitarias.

Darle mantenimiento a un proyecto así es más complejo de lo necesario, por varias razones:

1. Es más difícil encontrar la implementación concreta de un método porque la mayoría del código tiene llamadas a interfaces, debes buscar en otro proyecto la implementación.
2. La configuración necesaria es mayor, se necesita configurar todos los tipos en un contenedor de dependencias o usar el patrón de service locator (que tiene sus propias desventajas) para instanciar las clases concretas que implementan las interfaces del core.
3. La cantidad de código escrito es mayor (sin ningún beneficio, si solo tienes una implementación), por lo tanto entenderlo es más complicado.
4. Como la cantidad de código es mayor, hay mayor posibilidad de bugs. 
5. Un cambio trivial puede significar realizar cambios a todas las capas, debido a las abstracciones con fugas.

Aún conociendo esas desventajas y haber tenido que mantener proyectos de este tipo, donde incluso he visto que se agregaran abstracciones para obtener la fecha y hora del sistema. Aun así cuándo estoy por iniciar un proyecto nuevo, tengo esa sensación de dejar "puro" el dominio y las implementaciones concretas declararlas en otro proyecto. Aún sabiendo que no vale la pena, como que se antoja dejarme llevar en ese viaje creando abstracción sobre abstracción.

A veces siento que he logrado separarlo en capas, con moderación, limitando mis abstracciones. Es decir sin llegar al extremo de tener puras interfaces en el dominio. Pero casi siempre tengo que recordar que "No voy a necesitar otra implementación", pensar en YAGNI y el principio KISS. Recordar que siempre puedo refactorizar si se llega a ocupar. el refactoring es fácil porque el código es poco.  

Siempre es más fácil agregar una capa después, que darte cuenta que no la ocupabas y tratar de quitarla. Limitemos nuestras abstracciones.