En travaillant sur le livre "Implementing Domain Driven Design" de Vaughn Vernon, je suis incapable de bien comprendre ce qu'est un contexte délimité.
Le livre définit un contexte délimité comme "une frontière conceptuelle dans laquelle un modèle de domaine est applicable. Il fournit un langage omniprésent qui est parlé par l'équipe et exprimé dans son modèle logiciel soigneusement conçu" (la section "Guide de préparation de ce livre"). Cette définition donnerait l’impression qu’un contexte délimité est le modèle et le langage d’un sous-domaine, où ce sous-domaine peut devenir le domaine principal (ce qui semble devoir être qualifié de "sous-domaine principal", mais une autre discussion ...). Cela laisse encore une certaine ambiguïté quant à ce qu'un contexte délimité fournit. Est-ce un groupe d'un ou plusieurs sous-domaines? Si un seul sous-domaine correspond à un contexte lié, que nous dit réellement le contexte lié?
Le chapitre 3 du même livre, cependant, fait référence aux techniques d'intégration entre des contextes liés. Cela semblerait toutefois impliquer que les contextes délimités sont en réalité des systèmes logiciels ou des artefacts de différentes variétés.
Martin Fowler discute brièvement de l’idée d’un contexte délimité ( http://martinfowler.com/bliki/BoundedContext.html ), mais ne clarifie pas vraiment la question.
En fin de compte, qu'est - ce qu'un contexte délimité? Est-ce un groupe de sous-domaines? Le modèle et le langage pour un sous-domaine? La mise en place d'un sous-domaine? Sans ces réponses, il semble assez difficile de comprendre comment décomposer un espace de problème réel dans des contextes limités.