Escribo sobre lo que aprendo construyendo.

Tener casos de uso, entidades y repositorios no garantiza Clean Architecture. Con un sistema de gestión de flotas como ejemplo, el artículo muestra cómo las entidades anémicas convierten el código en transaction scripts disfrazados y guía la migración hacia un domain model: un objeto Chassi que se valida a sí mismo, atributos protegidos, un método de creación con valores por defecto y casos de uso que solo orquestan las reglas.

La modularidad va más allá de dividir el código en capas técnicas. El artículo explica cohesión y acoplamiento, muestra por qué la arquitectura en capas genera mucha comunicación entre módulos y casi ninguna dentro de ellos, y defiende la modularización por dominio de negocio, inspirada en DDD. El resultado son módulos cohesivos, desacoplados y listos para convertirse en servicios independientes cuando el dominio madure.

Los microservicios no son resilientes por naturaleza. Partiendo de las ocho falacias de la computación distribuida, el artículo muestra que cambiar llamadas en memoria por llamadas de red crea nuevos puntos de falla, y que la resiliencia depende de lo que cada servicio necesita garantizar. Un sistema nunca es resiliente a todo, sino resiliente a algo.

Ramas y commits sin estándar convierten el historial en ruido. El artículo enumera los problemas de los nombres vagos y los mensajes confusos y muestra cómo los estándares de nombres de ramas y los commits semánticos, con el formato prefijo(módulo): descripción, hacen que el repositorio se documente a sí mismo.