Envoyé par
marc.collin
bravo pour le tutoriel
en couplant tes entités, tu brises un peu le concept de package by feature architecture
il aurait été possible de passer par des id, sinon de copier les données et de passer par un événement pour les mettres à jour, suppression...
Bonjour Marc.collin,
Tu as parfaitement raison, la contrainte du package by feature vient vraiment des "ressources" qui sont partagées entre domaines. J'étais bien conscient que je n'ai pas fait un aboutissement de cette architecture dans l'article. Le but est dans un premier temps de sensibiliser le lecteur sur cette architecture qui apporte son lot de concepts, d'avantages et d'inconvénients. Si le lecteur s'y intéresse, il ira chercher plus d'infos.
Les solutions que l'on peut proposer pour adresser ce problème sont multiples, chacune possédant ces avantages et inconvénients. Pour la solution que tu proposes de copier les données et de d'utiliser l'event sourcing pour les mettre à jour, c'est bien, mais ça passe par une duplication de données et la mise en place de l'event sourcing pour mettre à jour chaque domaine. C'est complexe et impossible d'expliquer tout cela dans un seul et même article
.
Je peux même aller plus loin en disant que l'on peut même mettre en place le pattern
Capture Data Change couplé à Kafka qui se chargera de mettre à jour la/les tables de chaque domaine. Là encore c'est très complexe et trop de travail rien que pour respecter le principe du package by feature.
Il vaut mieux s'y investir sur tout ce que nous venons de citer lorsqu'on est vraiment en contexte Microservice ou une vraie architecture domaine driven.
D'autres son de cloche, disent de sortir exceptionnellement les "ressources" partagées (en veillant à ce que cela ne devienne pas un fourre tout) dans un package "common" afin que les différents domaines se les partagent. Ce n'est pas moins intelligible, après tout c'est une organisation dans un seul et unique projet.
Cordialement,
Georges
1 |
0 |