Parnas et Cockburn : comment s'imbriquent leurs deux visions

· Publié le · 2 min de lecture

Architecture logicielle : voici comment s’imbriquent les visions de Parnas et Cockburn.

Je recommande de lire mes articles précédents sur la vision de Parnas et celle de Cockburn, mais si je résume :

Les deux visions en bref

  1. David Parnas (1972, puis 2002) : dans un programme, de bons modules cachent les décisions arbitraires susceptibles de changer (ex : PostgreSQL vs Mongo) et/ou ce qui, si visible, réduit le nombre d’implémentations possibles du module (ex : userId = string plutôt qu’un type UserId, qui peut être un integer, une string, autre…).
  2. Alistair Cockburn (2005) : le Port/Adapter pattern, ou Architecture Hexagonale => pour être plus facile à tester et/ou être pilotable par plusieurs acteurs (utilisateur, CLI, script, autre), un bon programme protège son code métier intérieur des choix technologiques extérieurs, le tout via un système de Ports qui définissent des contrats de conversation (par exemple une interface UserRepository) et d’Adapters, qui sont les implémentations technologiques compatibles avec ces Ports (ex : PostgresUserRepository, InMemoryUserRepository).

Comment ces visions s’imbriquent

Maintenant, le cœur du sujet :

  1. Le Port/Adapter de Cockburn n’est qu’une application tactique de la vision stratégique de Parnas (au sens courant, rien à voir avec le strategic/tactical DDD d’Evans), pour répondre à un objectif de décomposition : séparer les technologies extérieures et le code métier intérieur, pour rendre ce dernier plus facilement testable et réutilisable.
  2. Chaque duo Port/Adapter de Cockburn est un module au sens de Parnas. Il permet de cacher un choix technologique arbitraire (critère numéro 1) au code métier tout en permettant un maximum d’implémentations (critère numéro 2) si le Port est bien pensé.

À noter pour finir

  • Le Port/Adapter pattern n’est qu’une tactique (aussi répandue et efficace soit-elle) pour appliquer la stratégie de Parnas à la séparation métier/technologies. Il en existe d’autres.
  • La stratégie de Parnas est beaucoup, beaucoup plus généraliste que le P/A pattern. On peut l’appliquer à tous les niveaux, de façon récursive, et sur de nombreux champs d’application (par exemple, à l’intérieur du code métier, on peut avoir une hiérarchie complexe de modules appliquant la stratégie de Parnas pour des besoins variés).

Choisir la bonne tactique pour chaque décomposition, c’est le genre de question de design que je travaille avec les équipes.

Bon designs !

Sources