Czym, w odniesieniu do DDD, jest kontekst ograniczony?

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.

Ograniczone konteksty i poddomeny istnieją na różnych poziomach.

Subdomena to część przestrzeni problemu, jest to naturalny podział systemu, często odzwierciedla strukturę organizacji. Dlatego logistykę i operacje można oddzielić od fakturowania i fakturowania . Eric rozróżnia podstawowe , wspierające i ogólne poddomeny zgodnie z ich istotnością biznesową w danym scenariuszu.

Konteksty to fragmenty przestrzeni rozwiązań. To są modele . Dobrze byłoby mieć je, odzwierciedlając podział domen na subdomeny ... ale życie nie zawsze jest takie łatwe. Być może rozdęłaś starszą domenę obejmującą wszystko lub więcej kontekstu w tej samej subdomenie (tj. Stara starsza aplikacja, którą zastępuje aplikacja, którą ktoś buduje).

Aby mieć ograniczony kontekst , musisz mieć model i wyraźną granicę wokół niego. Dokładnie tego, czego brakuje w wielu aplikacjach opartych na danych, które korzystają z baz danych do udostępniania danych.

Inny - ortogonalny - sposób, aby to zobaczyć, może być następujący. Wszechobecny język , specjalny warunek, w którym każdy termin ma jedną jednoznaczną definicję, nie jest skalowany. Im bardziej ją powiększysz, tym bardziej wkrada się dwuznaczność. Jeśli chcesz osiągnąć precyzyjne, jednoznaczne modele, musisz wyraźnie określić ich granice i mówić wieloma małymi, wszechobecnymi językami, każdy w ramach jednego ograniczonego kontekstu, w ściśle określonym celu .

Techniki projektowania opartego na domenach pomagają nam tworzyć modele świata, w którym żyjemy. Modele te istnieją jako pomysły w umysłach osób zaangażowanych w projekt.

Ponieważ telepatia jest wciąż w powijakach, pomysły te są przekazywane między ludźmi za pomocą słów i zwrotów.

Słowa i wyrażenia mogą być dwuznaczne w najlepszych momentach. Aby pomóc nam zmniejszyć dwuznaczność, używamy „kontekstu”, aby wyjaśnić ich znaczenie.

Kiedy ludzie są głęboko zanurzeni w projekcie oprogramowania, który obejmuje lata, wydaje się, że zapominają kontekst, z którego pochodzą pomysły, które zamieniły się w słowa, które zamieniły się w nazwy zmiennych, które zostały upieczone w kodzie.

Nowicjusze przybywają do projektu i zaczynają korzystać z jego języka. Być może są to użytkownicy, a może deweloperzy. Jeśli nie zostanie im zapewniony kontekst, wymyślą własny kontekst (a zatem znaczenie) z własnego doświadczenia życiowego.

Ten nowo zastosowany kontekst pokaże, jak nowi programiści dokonują refaktoryzacji lub opracowują kod. Jeśli zastosują niewłaściwy kontekst, dokonają refaktoryzacji i opracują kod w, być może bardzo nieznacznie, niewłaściwym kierunku. Niewłaściwe kierunki, choć niewielkie, mogą powodować znacznie większe problemy w dalszej linii.

Moim zdaniem „kontekst ograniczony” jest po prostu „kontekstem wyjaśnionym”, który jest przekazywany początkującym projektantom, aby nie stosowali własnego kontekstu w celu skażenia naszego, pięknie szlifowanego modelu.

Jest to wyraźne potwierdzenie przez zespół, że this phrasew this part of the projectsensie dokładnie this thing(a nie, jak mogłoby się wydawać, that thing).

Tak jak dobrze jest wyznaczyć granice między ogrodem a ogrodem sąsiada. Granicę określasz wyraźnie, abyś nie złościł się, gdy zaczną kopać kwietnik na idealnie wypielęgnowanym trawniku.

To jest to. To bardzo prosty pomysł, który jest tak ważny, że napisano o nim wiele.

Więc tak. Kontekst ograniczony jest dosłownie granicą, „ogrodzeniem”, która odróżnia kontekst jednej subdomeny od kontekstu innej subdomeny w projekcie.

Model i język subdomeny są odizolowane od innych modeli i języków, aby uniknąć dwuznaczności w znaczeniu.

Ale tak. Świat nie jest taki prosty.

Ty i zespół musicie być rygorystyczni w przestrzeganiu określonego kontekstu. Bardzo łatwo jest być leniwym i ponownie wyobrazić sobie kontekst, w którym można skracać rogi podczas tworzenia oprogramowania.

Ponadto rzeczy wchodzą w interakcje z innymi rzeczami, a ograniczone konteksty również muszą oddziaływać ze sobą. Istnieją więc różne wzorce opisujące, w jaki sposób zachodzą te interakcje. Zobacz Erica Evana w książce Domain Driven Design Rozdział 14 na temat tych różnych wzorców: wspólne jądro, dostawca klienta, konformista, warstwa antykorupcyjna, oddzielne sposoby, otwarta usługa hosta, język publikowany.

Zasadniczo kontekst Bounded określa pewne namacalne granice zastosowania niektórych subdomen. Jest to jakiś abstrakcyjny obszar, w którym pewna poddomena ma sens, a inne nie. Może to być rozmowa, prezentacja, projekt kodu z fizycznymi granicami określonymi przez artefakt.

W różnych sytuacjach używam trzech różnych perspektyw lub metafor koncepcji Bounded Context.

Z perspektywy czasu reprezentuje logiczne granice, zdefiniowane umową usługi, w której model jest implementowany. Umowa może być reprezentowana jako interfejs API tej usługi lub zestaw zdarzeń, które publikuje i wykorzystuje. Tak więc z tej perspektywy Ograniczony kontekst nie ma nic wspólnego z fizycznymi granicami.

Z perspektywy eksperta w dziedzinie ograniczony kontekst jest obszarem, w którym wdrażane są pewne procesy biznesowe, stosowany jest pewien wszechobecny język, a niektóre terminy mają wyraźny sens, podczas gdy inne nie. To tylko prostokąt narysowany na kartce papieru lub tablicy.

Dla programisty, tj. Z perspektywy kodu statycznego, ograniczony kontekst reprezentuje sposób, w jaki projektowałem moje modele wokół odpowiednich subdomen. Z iloma bazami kodowymi konkretna subdomena jest zaimplementowana? Z czego składają się pojęcia? Jakie koncepcje mają zastosowanie w każdej z nich? Dlatego mówi się, że ograniczone konteksty należą do przestrzeni rozwiązań.

Bardzo podoba mi się ten przykład koncepcji Bounded Context.

Kolejnym ważnym pytaniem (jeśli nie najważniejszym) jest to, jak rozpoznać ograniczone konteksty . Jeśli zrobisz to niepoprawnie, skończysz z gadatliwymi, niemożliwymi do utrzymania i ściśle powiązanymi usługami , znanymi również jako rozproszony monolit .