I.3. Strategic design
Comme nous avons dit, le langage nous permet de comprendre le domaine (ou plutôt mieux connaître le domaine).
I.3.1. Le bounded context
Généralement, cette compréhension nous permets d’identifier dans la complexité du domaine un ensemble de bounded context (des contextes bornés).
L’identification et la construction de ces bounded context est appelée le strategic design.
Parmi les caractéristiques de bounded contexts:
- Chaque bounded context peut contenir des bounded context et des modèles.
- Les modèles sont encapsulés dans un bounded context
- Les contextes sont indépendants, mais des échanges doivent exister.
- Les bounded contexts dans une architecture microservices
Dans une architecture microservices, la modélisation des bounded contexts doit être faite en prenant en considération le principe de la structuration à grande échelle (Large scale structure) que nous détaillons dans la suite de ce document.
Les bounded contexts on un rôle majeur dans la conception des microservices, souvent, comme ils sont des contextes séparés par des frontières tel que le nom l’indique, nous pouvons les voir comme des microservices.
NB: Les microservice n’ont pas toujours forcément la granularité du Bounded context. Ils peuvent avoir la granularité des agrégats dans le model-driven design.
I.3.2. Le context map
La communication qui peut exister entre les bounded contexts nécessitent un développement de ce qu’on appelle un concept map ou (context map dans des bounded contexts).
Pour développer un context map plusieurs patterns existent en DDD:
- shared Kernel
- Consumer/supplier
- Conformist
- Anticorruption layer
- Separate ways
- open/host
- Publish language
Sans aller dans les détails dans chacun des patterns, nous retenons ce qui est nécessaire pour nous dans l'architecture microservices, à savoir :
- Anticorruption layer
une communication qui développe une couche qui permet de ne pas modifier les modèles dans deux bounded contexts différents.
- Separate ways
un pattern de non communication entre deux contexts. Et donc une indépendance totale entre les contexts du domaine et donc entre les équipes de développement, si on considère que chaque contexte est un microservices.
- Open / HOST Service
un pattern qui permet d’exposer des services et de les intégrer après. Nous pouvons voir cela par exemple comme une communication REST entre deux services dans une architecture microservices.
NB: pour schématiser un concept map. Eric evans, utilise dans son livre une certaine représentation spécifique en diagrammes, pour les patterns de communication.
Il faut savoir que l’utilisation des différents patterns influence à plusieurs niveaux la communication et l’organisation des équipes de développement.
Par exemple: il faut savoir que l’utilisation du pattern publish language peut être dangereux dans les microservices car il redéfini une sorte d’Ubiquitous Language sous forme de services exposés similaires au pattern open/host. Ce qui rajoute de la complexité et crée une forte nécessité de communication entre les équipes. Comme celle qu’on a identifié dans la compréhension du domaine.
I.3.3. Distillation
La distillation est un processus de séparation de mélange de composants. A l’origine, C’est un terme chimique, où on a un mélange de liquides dont les températures d'ébullition sont différentes. Nous citons à ce niveau l’origine du terme pour mentionner que l'expérience peut se faire en plusieurs étapes.
Par analogie dans le monde DDD, nous pouvons imaginer la distillation s’appliquer sur le domaine de connaissances pour extraire les entités de base de notre domaine, les modèles. La finalité derrière cela est d’arriver à identifier, dans la complexité du métier, ce qu’on appelle le "CORE DOMAIN".