Jak jasno zdefiniować granice ograniczonego kontekstu

Po około miesiącu czytania i poszukiwania DDD postanowiłem rozpocząć własny projekt i stworzyłem DDD z tymi ograniczonymi kontekstami>

• Klienci
• Produkty
• Zamówienia
• Dane do faktury

Każdy ograniczony kontekst ma spoczynkowy interfejs API jako warstwę prezentacji, warstwę domeny, warstwę trwałą.

Jak na razie kod działa płynnie, ale pochodząc ze świata monolitycznego, wciąż próbuję wymyślić, co następuje:

• kiedy chcę utworzyć nowego klienta, wystawić nową fakturę, utworzyć nowe zamówienie Chcę na przykład uzyskać dostęp do listy krajów. Czy ja:

a) utwórz listę krajów w każdym BC

b) utwórz interfejs API BC -> Kraje i użyj go, aby uzyskać listę dostępnych krajów

c) używać interfejsu API innej firmy i pobierać dane przez warstwę antykorupcyjną w każdym BC

• jakie dane muszą być uwzględnione w moim modelu domeny podczas integracji z interfejsem API innej firmy przy użyciu warstwy antykorupcyjnej lub warstwy adaptera? Na przykład, jeśli chcę zintegrować API zendesk z Client BC. Czy potrzebuję tylko identyfikatora biletu w mojej domenie, czy też muszę wyodrębnić wszystkie dane z Zendesk, do których chcę uzyskać dostęp i których używam w kliencie BC?

Jeśli moja aplikacja MVC faktycznie pobiera dane z interfejsów API (warstw prezentacji moich ograniczonych kontekstów), bardzo trudno jest wyraźnie zdefiniować granice każdego BC. Czy to oznacza, że ​​odpowiednio zaprojektowany BC będzie obsługiwał pojedynczy kontroler MVC bez potrzeby korzystania z dodatkowych interfejsów API?

Jeśli twoje różne granice kontekstów różnie rozumieją znaczenie / cel kraju, musisz odpowiednio modelować go w każdym z nich. Jeśli jednak mówimy po prostu o danych referencyjnych kodów i nazw ISO, uważam, że dość uczciwe i standardowe jest przechowywanie ich w dogodnym miejscu i udostępnianie wszystkim zainteresowanym stronom. Na przykład: baza danych, plik konfiguracyjny, usługa internetowa itp.

Chciałem też trochę popatrzeć na twój model. Elementy, które wymieniłeś, mogą równie dobrze być „bytami” w jednym „ograniczonym kontekście”, w zależności od struktury firmy. BC często kończą się na różnych obszarach / działach / zespołach, ponieważ często jest to naturalna granica między „wszechobecnym językiem”. Na przykład zamiast sprzedaży / produktów / zamówień spodziewałbym się, że BC będą zgodne z kierunkiem sprzedaży / produkcji / magazynowania.

W tych BC nie skupiasz się na rzeczownikach. Skupiasz się na przypadkach użycia i tworzysz modele rzeczowników, które mogą spełnić przypadki użycia. Metody „zagregowanego katalogu głównego” wykonują przypadki użycia i wprowadzają odpowiednie zmiany w powiązanych modelach.

... wszystkie modele są złe, ale niektóre są przydatne.

Należy również pamiętać, że każdy BC może wykorzystywać zupełnie inny system lub architekturę. Dany BC może w ogóle nie zasługiwać na „komponenty oprogramowania DDD”, a większość z nich prawdopodobnie nie. W DDD mniej chodzi o nakazowe komponenty oprogramowania, a więcej o procesie projektowania oprogramowania. Chodzi o to, aby skupić się na zrozumieniu kontekstów ograniczonych przez firmę, odwzorowaniu wszechobecnych języków każdego kontekstu i modelowaniu kodu dla tego kontekstu przy użyciu ich wszechobecnego języka. W ten sposób, gdy wchodzisz w interakcję z interesariuszami i odnosisz się do kodu, brzmi to tak, jakbyś mówił w kategoriach biznesowych, które rozumieją. I uznanie, że to samo słowo ma różne znaczenie w różnych BC.

Istnieją specyficzne wzorce przedstawione przez DDD (np. Repozytorium, określone tworzenie warstw itp.), Które są środkiem do celu. Ale nie gwarantuje się, że te wzorce będą najlepszymi wzorami dla każdego przypadku, nawet w DDD. Podobnie jak DDD nie jest „odpowiedzią” dla każdego projektu. Musisz tylko zrobić to, co sugeruje twoja analiza, jest najbardziej praktyczną rzeczą do zrobienia.

Z twoich pytań myślę, że źle rozumiesz ograniczony kontekst. Możesz przeczytać ponownie rozdział 14 niebieskiej księgi .

Próbując odpowiedzieć ogólnie - musisz uważać na dzielenie się koncepcjami między dwoma różnymi kontekstami ograniczonymi. W końcu jedną z przyczyn istnienia granicy jest to, że zmienia się wszechobecny język. Zakładanie, że te same dane (i ta sama reprezentacja) bytu mogą być użyte w obu kontekstach, jest naiwne - może być słuszne, może być błędne, ale nie ma dobrego sposobu dla tych z nas na zewnątrz, bez dostępu do ekspertów w swojej dziedzinie, aby ocenić.

Na przykład w domenie klienta „kraj” może być powiązany z miejscem zamieszkania lub obywatelstwem. W rozliczeniach może to być związane z kursem wymiany walut. W niektórych z tych domen możesz martwić się o taryfy i tym podobne.

Drugim pytaniem, które musisz postawić, jest to, który z twoich modeli jest księgą rekordów dla „współdzielonych” danych. W przypadku „kraju” poprawną odpowiedzią jest prawdopodobnie to, że żaden z nich nie jest! Topologia geopolityczna nie jest kontrolowana przez Twój model.

Co powinno się stać w modelach domen, gdy kraj jest zajęty przez zagraniczne mocarstwo?

Pamiętać; wielu z nas jest przyzwyczajonych do myślenia o strukturze danych; jaki jest związek między jedną częścią danych a drugą. I to świetnie, gdy rozważasz raporty i starasz się, aby wszystkie potrzebne dane zostały zebrane przez twoje rozwiązanie. Ale modele domenowe to nie tylko struktura, ale także zmiana. Musisz także zwrócić uwagę na tę część i upewnić się, że dobrze rozumiesz, w jaki sposób dane ograniczają zmiany (i jak te ograniczenia różnią się w zależności od kontekstu ograniczonego).

Pojęcia, o których wspominasz (klienci, produkty, zamówienia, fakturowanie) są zazwyczaj reprezentowane w jednym modelu domeny, a zatem ograniczonym kontekście. Sugeruję, że źle rozumiesz te pojęcia.

Moje podejście do tego tematu polega na zdefiniowaniu ograniczonego kontekstu przy użyciu mapowania zdolności biznesowych lub innych podobnych technik, takich jak analiza łańcucha wartości. Sprowadza się do następujących kroków:

1. Zdefiniuj obowiązki wyższego poziomu systemu lub możliwości biznesowe. Myślę, że najlepszym sposobem, aby to zrobić, jest wyczarowanie kroków, przez które przechodzi twoje przedsiębiorstwo, aby uzyskać wartość biznesową. Logiczne granice, które wymyślisz, to twoje usługi biznesowe lub, jeśli chcesz, ograniczone konteksty.
2. Sięgnij głębiej w ramach każdej usługi.
3. Zidentyfikuj komunikację między swoimi usługami obok dwóch pierwszych punktów.

Tak więc początkowo skupiamy się na tym, jak działa Twoja firma.

Kilka praktycznych porad:

1. Jeśli jeden z twoich kontekstów / usług / etc potrzebuje danych innego kontekstu, najprawdopodobniej twoje granice są błędne.
2. Wysoce pożądany sposób komunikacji kontekstowej jest oparty na zdarzeniach. Jest to klucz do skalowalności i niezawodności. Jeśli potrzebujesz komunikacji synchronicznej, najprawdopodobniej granice się nie zgadzają. Poza tym synchroniczna komunikacja zabije twój system.
3. Twoja domena jest bardziej spójna niż myślisz. Tak jak wszyscy inni. Nie staraj się, aby wszystko było w 100% spójne. Nie ma to praktycznego sensu.
4. Konteksty nie wymagają aranżacji. Są samodzielne. Jak ludzie

Dzięki takiemu podejściu uzyskujesz wysoce autonomiczne, łatwe w utrzymaniu i niezawodne usługi. Możesz sprawdzić przykład definiowania granic kontekstu.