Par @cyriux & @tpierrain.
Deux axes de symétrie, un axe "API" | "SPI", et un axe "Verify behavior in tests" | "Deliver value to prod".
- API, Application Provider Interface = "They need me"
- SPI, Service Provider Interface = "I need them"
"Verify behavior in tests" et "Deliver value to prod" : les deux sont équivalent du point de vue de l'hexagone (du domaine), on ne fait pas de code spécifique pour l'un ou pour l'autre (les mêmes points d'entrée, les mêmes portes). Un robot de test n'est qu'un client / consommateur comme un autre, et un mock n'est qu'un fournisseur de services comme un autre.
"Beware of modelism!", on ne code pas le modèle pour être réaliste avec tout ce qu'il pourrait y avoir dans le modèle IRL, on va juste s'arrêter à ce dont on a besoin. Faire un modèle utile, pas réaliste mais utile, drivé par nos use cases.
Dessiner la DIP :
- non
[Account -]-x-[-> SPI] - oui
[Account -> Interface <-]---[- Adapter SPI]
Pattern repository : bien nommer l'interface avec un nom de domaine, par exemple CatalogueDeBonbons et pas BonbonRepository.
-
Côté API, c'est assez facile parce-qu'on appelle et on dépend dans le même sens.
-
Ça suppose que notre domaine a suffisament de matière pour être intéressant en lui-même, qu'il mérite de l'attention, qu'il mérite d'être grossi même sans l'infra. Si votre projet c'est juste un projet d'infra, de connectique, de plomberie entre applications, et qu'il n'y a pas vraiment de métier dedans, c'est pas pertinent.
-
Port = Techno existante
-
Adapter = Notre code