Pour rendre un système simple, utilisez des événements pour supporter les interactions entre de petits composants métiers, c'est ce qu'a suggéré Russ Miles lors d'une récente présentation Développer des composants Event Driven simples pour du logiciel agile.
Cette présentation fait suite à une autre qu'il a donnée un mois plus tôt, Des Evénements pour simplifier l'architecture d'un système, au cours de laquelle Russ a mis en place les bases de ses idées sur la Simplicité : une architecture où de petits composants collaborent entre eux en échangeant des Evénements.
Ce type de design permet à Russ d'être en situation de faire évoluer ces composants au même rythme que l'application ou le système en s'affranchissant des "frottements" entre eux qui font qu'un simple petit changement peut tout mettre par terre.
Pour Russ la base ce sont les composants, et la simplicité, le principe permettant de réduire le couplage entre eux. Comment évaluer si un composant est simple ou non ? Un bon test : est-il simple de déplacer le composant. Si le déplacement est difficile, c'est un bon indicateur de trop grande complexité. Il compare le déplacement d'un composant complexe avec une guirlande de Noël : on tire sur une lampe et tout le reste suit.
Pour simplifier un composant complexe, il sépare les responsabilités et les effets de bord en évacuant ceux-ci dans d'autres composants plus petits. Un exemple d'effet de bord, l'intégration avec le reste du monde, par exemple la production de logs, responsabilité que Russ déplace vers l'infrastructure.
Des événements supportent l'échange de données entre composants. A première vue, cela conserve un point de couplage, l'émetteur devant connaître le receveur. On l'élimine en introduisant un événement pivot intermédiaire et un système de distribution des événements.
La manière la plus simple d'implémenter un événement est une classe immutable partagée, mais cela introduit à nouveau du couplage. L'étape suivante de réduction de la complexité est de remplacer cette classe par des paramètres nommés (des paires clés-valeur).
Le coté négatif de cette approche, c'est l'indirection : selon Russ, cela diminue la complexité mais cela retarde la confrontation avec d'autres problème potentiels. La réponse : une bonne couverture de tests à la fois unitaires et d'intégration entre composants.