Ressource
Note
It’s crucial to remember that subdomains are discovered and bounded contexts are designed.
Il faut se rappeler que les sous-domaine est une partie du métier de l’organisation et existe naturellement dans l’organisation indépendamment de la modélisation logiciel. Il en existe trois types Core qui représente notre valeur ajoutée, Supporting qui soutient le core mais sans y apporter un avantage compétitif et finalement Generic qui correspond à des solutions que tout le monde utilise (e.g. Keycloack pour l’authentification)
Tandis que les Bounded Context c’est une solution technique et architecturale qui encapsule un modèle cohérent où l’on parte le même Ubiquitous Language, ses propres entités et règles métiers. Chaque BC est un service/projet qui peut être implémenté, versionné et évolué indépendamment des autres BC
Relations entre les deux
- Idéalement, on vise une relation 1:1 entre sous-domaines et bounded contexts
- Un sous-domaine peut être implémenté par un ou plusieurs bounded contexts lorsqu’il est complexe
Par exemple le sous-domaine Paiements peut avoir trois Bounded Context :
- Bounded Context 1 : Paiements en ligne
- Bounded Context 2 : Traitement des remboursements
- Bounded Context 3 : Détection de la fraude
Où la notion de Transaction dans le BC1 représente une opération de paiement initiée par un utilisateur via une plateforme de paiement (ex: Stripe, PayPal). Tandis que dans le BC3 cela représente un événement d’activité financière (paiement, remboursement, retrait, etc.) observé pour détection de comportement suspect, elle peut être enrichie de métadonnées (IP, localisation, device).