Notion de Seam

Problème du Monolithe

Nous voulons que nos services soient highly cohesive and loosely coupled. Le problème du monolithe est qu’il est trop souvent l’opposé de ces deux caractéristiques.

  • Plutôt que de tendre vers la cohésion et de garder ensemble des choses qui ont tendance à changer ensemble, nous acquérons et collons ensemble toutes sortes de codes sans rapport les uns avec les autres.
  • De même, le couplage faible n’existe pas vraiment : si je veux modifier une ligne de code, je devrais pouvoir le faire assez facilement, mais en réalité je ne peux pas déployer cette modification sans avoir un impact potentiel sur une grande partie du reste du monolithe. Je devrai certainement redéployer l’ensemble du système

Concept de Seam

Seam : une partie du code qui peut être traitée de manière isolée et sur laquelle on peut travailler sans avoir d’impact sur le reste du système

Dans son livre Working Effectively with Legacy Code (Prentice-Hall), Michael Feathers définit le concept de Seam. Nous voulons donc identifier les seam qui peuvent devenir des service boundaries

Ainsi les bounded context sont de bonnes seam car par définition ils représentent un ensemble cohérent et faiblement couplé.