L'architecture est une affaire d'intention, nous en avons fait une question de frameworks et de détails. C'est le constat qu'a fait Robert C. Martin, "Uncle Bob", au début de l'année au DDD Exchange Day de Londres.
Robert renvoie au modèle architectural décrit dans le livre Growing Object-Oriented Software Guided by Tests, (similaire à l'Architecture Hexagonale), qui décrit une architecture divisée en trois zones dont les dépendances ne vont que dans un sens, des plus volatiles vers les plus stables.
- Un Modèle de Domaine contenant les règles du coeur de métier, la partie la plus stable et importante qui ne dépend de rien d'autre
- Des Services Applicatifs pour les Cas d'Utilisation du système, qui utilisent et dépendent du Modèle de Domaine
- Des détails externes, une base de données, des interfaces utilisateurs, un réseau, etc... qui sont moins pertinents par raport au Modèle de Domaine. C'est la partie la plus volatile qui dépend des deux autres.
Robert remarque que ce modèle échoue à décrire ce qu'il considère comme un point clé : l'architecture est liée à l'Intention, ce que FAIT l'application. Il pense qu'on se focalise trop sur les détails et les frameworks jusqu'à en faire le centre de nos systèmes.
Pour résoudre ce problème Robert revient au livre d'Ivar Jacobson, "Le génie logiciel orienté objet, une approche fondée sur les cas d'utilisation", paru en 1992, dans lequel Ivar définit un mécanisme pour produire une architecure applicative en s'appuyant sur de petits cas d'utilisations peu détaillés.
Robert explique qu'Ivar propose trois types d'objets, qui s'insèrent naturellement dans le modèle architectural :
- Les Interacteurs qui comprennent les Cas d'Utilisation et contiennent les règles métier spécifiques
- Les Entités contenant les règles métiers, utilisées par les Interacteurs
- Les Objets Frontières qui transfèrent les données entre le monde extérieur et les Interacteurs
Robert affirme que l'avantage significatif de ce type de modèle est sa grande testabilité : il peut être testé sans dépendre de l'infrastructure, uniquement via l'envoi et la réception de structures de données à travers les Objets Frontières.
Robert passe ensuite à son modèle d'Architecture Propre, une variante de la précédente. Un aspect essentiel des trois modèles cités est qu'ils suivent le Principe de relation Dépendance/Stabilité ou SDP : "Ne pas dépendre de choses qui changent ou qui vont probablement changer". Les modèles précédents satisfont ce principe en faisant dépendre les parties externes les plus volatiles des parties les plus stables comme le Modèle de Domaine et pas le contraire. Cela simplifie aussi les évolutions d'implémentation, les parties volatiles dépendant de quelque chose de stable. Pour citer Robert :
Une bonne architecture permet de remettre en cause facilement des décisions volatiles
Robert évoque aussi Jim Coplien et son Architecture DCI similaire, selon lui, aux précédentes.
Certaines des idées que Robert a exprimées ces dernières années ont donné lieu à des critiques auxquelles il a apporté des réponses.