Podczas pracy nad książką „Implementing Domain Driven Design” autorstwa Vaughna Vernona nie byłem w stanie dobrze zrozumieć, czym właściwie jest ograniczony kontekst.
Książka definiuje ograniczony kontekst jako „konceptualną granicę, w której ma zastosowanie model domeny. Zapewnia wszechobecny język, którym posługuje się zespół i który wyraża się w jego starannie zaprojektowanym modelu oprogramowania” (sekcja wstępna „Przewodnik po tej książce”). Ta definicja sprawiłaby, że brzmiałoby to tak, jakby kontekstem ograniczonym jest model i język subdomeny, gdzie ta subdomena może być domeną rdzeniową (co wydaje się, że powinna być nazywana „subdomeną rdzeniową”, ale to jest kolejna dyskusja ...). To wciąż pozostawia niejasności co do tego, co zapewnia ograniczony kontekst. Czy jest to grupa jednej lub więcej subdomen? Jeśli tylko jedna subdomena odpowiada ograniczonemu kontekstowi, co tak naprawdę mówi nam ten ograniczony kontekst?
Rozdział 3 tej samej książki odnosi się jednak do technik integracji między ograniczonymi kontekstami. Wydaje się to jednak sugerować, że ograniczone konteksty są w rzeczywistości systemami oprogramowania lub artefaktami o różnej różnorodności.
Martin Fowler krótko omawia ideę ograniczonego kontekstu ( http://martinfowler.com/bliki/BoundedContext.html ), ale tak naprawdę nie wyjaśnia problemu.
Na koniec, jaki jest kontekst ograniczony? Czy to grupa subdomen? Model i język subdomeny? Wdrożenie subdomeny? Bez tych odpowiedzi wydaje się raczej trudne do zrozumienia, jak rozłożyć rzeczywistą przestrzeń problemową na ograniczone konteksty.