fbpx

Bounded Context

5 komentarzy

  1. Innym wartym wspomnienia sposobem na realizację komunikacji między kontekstami jest model zdarzeniowy.

  2. W ogólności konteksty mogą integrować się poprzez:
    – dane – gdzie np Repozytorium jednego kontekstu pobieranie sobie część danych z serivsu apliakcyjnego drugiego kontekstu (drugi kontekst ukrywa model, zwraca rodzaj projekcji)
    – czynności – najprostszy scenariusz, gdzie po prostu wołamy serwisy z innego kontekstu
    – zdarzenia – o których właśnie pisał Krzysztof. Dają nam decoupling (ze wszystkimi konsekwencjami), umożliwiają odcięcie się od strzałki czasu (asynch), architekturę pluginową…
    A orkiestracja wielu zdarzeń jest możliwa dzięki Sagom biznesowym.

    Ale za każdym razem kluczowe jest hermetyzowanie modelu danego kontekstu (znowu zasada OO na poziomie arch. apliakcji).

  3. @Sławek

    Nie mogłem już dłużej wytrzymać braku postów na twoim blogu i wiedziałem, że to Cie sprowokuje 🙂

    Spójrzmy przez pryzmat DDD na rozdział From the Mud to Structure z POSA 4. Takie np. Shared Repository przedstawia komunikację między komponentami poprzez dane. Dobre dla systemów data-driven – np. jakieś aplikacje pomiarowe. Mejk sens?

  4. ToJaJarek pisze:

    Czy przypadkiem przekazanie "czegoś" do innego kontekstu to nie "żądanie", które w odpowiedzi dostaje "obiekt" w odpowiedzi, nie koniecznie "żądany" obiekt a jego "kopię" lub wersję?

    Jeżeli konteksty były by obsługiwane przez odrębne podsystemy (komponenty) przekazanie czegokolwiek między nimi właśnie tak by wyglądało (to coś jak zaświadczenie w urzędzie: dostaje jakiś pełny lub częściowy odpis tego co urząd ma…)