Erase una vez cuando se desarrollaban aplicaciones grandes, con decenas o incluso cientos de entidades. Era una época donde se esperaba que cada pieza de software viviera por muchos años y los ciclos de release podían extenderse por muchos meses excediendo incluso el año. Era una época donde la programación orientada a objetos y sobre todo un buen modelo de objetos podía marcar una diferencia relevante en la construcción, evolución y mantenimiento de una pieza de software[1].

Pero esa época ha quedado atrás, cada vez son más las demandas del negocio por dar respuestas rápidas a las situaciones cambiantes del mercado. Los ciclos de release se han acortado radicalmente y de mano de ello también alcance de cada aplicación. Los avances en virtualización y la popularización de los contenedores han habilitado el surgimiento de prácticas como infraestructura como código y continuous delivery. En este contexto, propuestas de diseño como la de microservicios han probado ser muy efectivas. Cada microservicio es una aplicación de un tamaño acotado, no hay un regla fija de esto pero se suele usar como referencia un bounded context [2]. En este hilo de razonamiento cada aplicación no tiene ya tantas entidades y tampoco se espera que un microservicio «viva por siempre». Dado que los microservicios son relativamente pequeños no resulta impensado que luego de un tiempo sea reemplazado por una nueva versión que podría estar incluso desarrollada con una tecnología distinta.

Esto me lleva a pensar que en cierto modo la importancia de la programación orientada a objetos ha perdido cierta importancia relativa. En un punto cuestiones como la arquitectura de runtime (que impactan en la posibilidad de escalar) han tomado mayor relevancia (posiblemente porque la necesidad de escalar está mucho más presente ahora que hace 15 años).

Sin embargo estoy convencido que los principios de la orientación siguen completamente vigentes porque muchos de ellos son aplicables más allá de la programación. De hecho, los principios de diseño de los microservicios no son más que «refraseos» de los principios de orientación objetos. Un caso es el principio de Responsabilidad Única (Single Responsibility Principle): un objeto debe hacer UNA cosa y hacerla bien, eso mismo aplica a los microservicios. De hecho creo que perfectamente uno podría tomar los principios de orientación a objetos, aplicarlos al diseño de microservicios y luego programar internamente el microservicio utitilizando objetos pero de una forma más «procedural» utilizando alguna estrategia del Transaction Script. en lugar de hacer un Domain Model.

Tal vez este razonamiento genere alguna crítica y ante ello debo aclarar que he estado enseñando Programación Orientada a Objetos por más de 15 años y aún lo hago. Pero desde hace un tiempo vengo con la sensación de que en la medida en que podamos hacer aplicaciones/servicios pequeños, con pruebas automatizadas y prácticas de configuración management, la forma interna en que programemos las aplicación, resulta menos relevante.

[1] Posiblemente en algunos contextos esto siga ocurriendo
[2] Bounded Context es una idea desarrollada por Eric Evans en su libro Domain-Driven Design