Anti Exceso de Arquitectura de Software

Creo que se ha sobredimensionado ridículamente esto de despiezar objetos en mil clases, capas y proyectos como si eso fuera sinónimo de buena arquitectura. Terminan creando una clase para cada verbo, otra para mapear, otra para validar, otra para inyectar... y luego se preguntan por qué su proyecto tiene más carpetas que lógica de negocio.

No veo por qué un objeto bien hecho, con sus propiedades claras, métodos privados, lógica encapsulada y unas cuantas inyecciones de dependencias para servicios externos, no pueda ser escalable, mantenible y entendible por varios desarrolladores. ¡Para eso existe Git! Para colaborar, revisar y coordinar la edición de un archivo de código.

Además, eso de separar la lógica del dominio como si el objeto no pudiera pensar por sí mismo es un retroceso, no un avance. Justo la idea de la programación orientada a objetos es que los objetos tengan estado y comportamiento, no que sean entes casi vacíos a los que les tienes que "inyectar" acciones desde comandos externos.

La complejidad solo se justifica si resuelve un problema real, no por moda o por seguir el patrón del tutorial de turno. Entonces sí: prefiero un objeto que hace su trabajo, con todo su cerebro adentro, a tener un pobrecito objeto despiezado en una procesión de clases casi eunucas.