La modularité est ton amie
Une bonne modularité est ce qui vous permet de supporter une piètre qualité logicielle localement, et de refactorer au fur et à mesure. S'il y a bien une chose à anticiper et ne pas louper dans votre système d'information, c'est donc sa modularisation.
Bien que tendancieuse, cette première phrase comporte du vrai. Voyons cela ensemble.
Si l'architecture d'un contexte est bancale, que la technologie sur laquelle il repose est obsolète ou que sa qualité de code laisse à désirer, si la dette technique dépasse celle de la France et que rien ne ressemble à un test, gardez à l'esprit qu'une bonne modularité en limite les conséquences sur le reste du système d'information, par construction. Le contexte d'à-côté peut très bien être un petit bijou de développement et n'être nullement pollué par le premier, et cela grâce à une modularité bien travaillée.
Le sujet est d'autant plus intéressant qu'il ne coûte rien, vraiment rien quand on s'y penche à T0, dès les premières heures de vie d'un produit. Et là, je m'adresse à toutes les start-up : à ce stade, vous travaillez sur un seul contexte, il n'y a donc rien à refactorer à grande échelle et cette réflexion additionnelle se fait entièrement sur papier. Pourtant, c'est peut-être grâce à elle que votre entreprise vivra bien son scale-up d'ici quelques années. Il est donc impensable de ne pas vous y intéresser.
C'est l'occasion de rappeler, s'il en était encore besoin, que s'intéresser au Domain-driven design tactique avant de s'intéresser au stratégique n'a aucun sens : c'est le "on ne sait pas où l'on va, mais on y va", que l'on voit malheureusement trop souvent.
En conclusion : no stress. Vos contextes ne sont pas aussi beaux que vous le voudriez ? Soit. Si déjà ils sont correctement définis et communiquent proprement, c'est énorme. C'est 90% du travail et un avantage incommensurable sur le long terme.
En passant, j'utilise le mot "contexte" comme une évidence, mais il nécessite peut-être un rappel. Les contextes, au sens du Domain-driven design, sont des zones de cohésion forte couplées faiblement les unes aux autres. Dit autrement, le bon contour des contextes est celui qui minimise le besoin de communication entre ces derniers.
Comment identifier les frontières entre contextes ? Pour faire simple, un contexte est la traduction d'une action métier, d'une finalité opérationnelle. "Facturation" est toujours un contexte, tandis que "Produit" ne sera jamais un contexte (je peux faire mille choses avec un produit : le fabriquer, le vendre, l'expédier, le facturer, le recycler…) "Front-end" ne sera jamais un contexte, non plus (c'est un découpage technique).
Quant aux modalités de communication entre contextes, il y en a 2 : les appels directs et l'architecture événementielle (Event-driven architecture).
Et enfin, pour le déploiement : oui, vous pouvez faire des microservices si vous avez le sens de l'humour, ou la folie des grandeurs, et sinon un bon monolithe modulaire fera l'affaire !