Domain-Driven Design Bounded Context

Każdy model powstający na podstawie rozmów z ekspertami domeny jest poprawny, ale tylko w obrebie jakiegoś kontekstu. Gdy tworzymy prostą aplikację, kontekst jest jeden i czesto niejawny. W bardziej skomplikowanych systemach, mogą istnieć pojęcia, które dla różnych ekspertów domenowych znaczą co innego. Być może tens sam koncept nazywany jest inaczej. Dla przykładu, dla pracownika odpowiedzialnego za wystawianie dokumentów, faktura znaczy co innego niż dla księgowego liczącego przychody. Jak zamodelować taki obiekt w systemie. Jak stworzyć wspólny język, „Ubiquitous Language”?

Należy w modelu  wprowadzić ograniczone konteksty (ang. Bounded Contexts). Są Oznaczają części aplikacji, z których każda posiada dokładnie zaznaczone granice i swój model. Każda z nich jest odpowiedzialna za inny aspekt biznesu i dzięki takiemu podziałowi łatwiej stwierdzić, gdzie powinna się znajdować poszczególna logika biznesowa. Bounded Context nie jest równoznaczny z modułem. Moduły używane sa do organizowania elementów modelu, natomiast kontekst jest obszarem o ściśle wyznaczonych granicach, w którym rozwijany jest model.

Poza tym może się zdarzyć tak, że w różnych kontekstach będą używane te same terminy, ale ze względu na miejsce, w którym się znajdują, będą miały różne znaczenie. Dzieje się tak dlatego, że każdy pojedynczy kontekst może posiadać swój język niezależny od pozostałych. Taki podział niesie ze sobą następujące zalety:

• Modułowość (ang. Modularity)

• Rozdzielenie pojęć (ang. Separation of Concerns)

• Luźne powiązania pomiędzy modułami (ang. Loose Coupling)

• Niezależne rozwijanie kontekstów

Komunikacja i powiązania pomiędzy kontekstami opisane są w dokumencie zwanym mapą kontekstu (ang. ContextMap). Jasno zdefiniowane granice kontekstów mają służyć zlikwidowaniu współdzielenia obiektów i operacji pomiędzy kontekstami. W tym podejściu potrzebna będzie nowa warstwa translacji, ale zysk z posiadania jasno zdefiniowanych kontekst zdaje się przewyższać konieczność jej stworzenia.

Zeby utrzymać jasne granice pomiędzy kontekstami przez całe zycie systemu trzeba zadbać o stworzenie odpowiednich testow integracyjnych, które bedą pilnować kontraktu w warstwie translacji.  Przydadzą się również testy jednostkowe pilnujące konceptów domeny biznesowej w poszczególnych modelach. I to wszystko w postaci Continous Integration.