Pour délivrer de la valeur chez nos clients, nous sommes amenés à développer des applications numériques. Le code source de celles-ci traduit les fonctionnalités qui vont permettre à nos clients de se différencier des autres, de faciliter les usages de ses utilisateurs, de faire plus de bénéfices, […].

Pour se comprendre, entre équipe produit et métier, nous portons des méthodologies de travail comme le BDD (Behavior-Driven Development). Les besoins deviennent des fonctionnalités, les fonctionnalités deviennent des cas d’usage. Nous pouvons alors entamer les développements. C’est là que nous arrivons à un détail qui à son importance: l’architecture logicielle. La manière de l’aborder peut avoir un impact significatif sur le produit final: sa maintenance, sa résilience, sa qualité.

L’architecture oignon est particulièrement adaptée pour répondre à des besoins métier à forte valeur ajoutée. Mais qu’est-ce que c’est ? Comment ça se traduit dans le code ? Quelle différence avec l’architecture hexagonale et l’architecture n-tiers ?

Revêtons notre plus beau tablier, partons d’un besoin, et découpons notre archi.