Konteksty i domeny związane z DDD?

Pracowałem w stosunkowo złożonej aplikacji z dziesięcioma tabelami bazy danych (agregaty, jednostki / obiekty wartości) i stosuję DDD. W tym momencie wydaje się, że jest to w zasadzie DDD-Lite, co oznacza, że ​​istnieją Usługi aplikacji / domen, Model domeny (Encje, Obiekty wartości) i Repozytoria.

Wziąłem książkę Implementowanie DDD, a pierwszą rzeczą, o której wspomina, są DDD-Lite i brak kontekstów i zdarzeń domeny jako pierwszych błędów, które są typowe przy rozpoczynaniu DDD.

Obecnie próbowałem zorganizować model domeny według relacji agregujących i użyć przestrzeni nazw, aby to zademonstrować.

Nie widzę korzyści / wad związanych z rozdzieleniem projektu Modelu Domeny na osobne konteksty Ograniczone (jeszcze). Być może okaże się to później, ale chciałbym uzyskać prawdziwe informacje zwrotne na temat ograniczonych kontekstów (i ewentualnie subdomen itp., Jeśli się z tym połączą).

Zastanów się nad firmą, która ma kilka różnych działów:

• Rozwój oprogramowania
• HR
• Księgowość

Czy możesz wymyślić model użytkownika, który może wyraziście reprezentować wszystkie te obszary działalności? Pomyśl, jak mogłaby wyglądać jednostka użytkownika w każdym z nich. Być może jest podzielony na trzy różne podmioty:

• Deweloper
• Pracownik
• Odbiorca płatności

Wysiłek utworzenia użytkownika w każdym kontekście jest znacznie inny. Być może jest to coś takiego:

• nowy pracownik (SSN, imię, nazwisko, data urodzenia, płeć)
• nowy programista (pracownik, stacja robocza, dane uwierzytelniające)
• nowy odbiorca (pracownik, rola)

wybacz przykład, trudno jest dokładnie zilustrować bez odpowiedniego modelu domeny, do którego można się odwoływać

Jeśli użyjesz naiwnej implementacji i użyjesz jednego użytkownika, skończy się to anemicznym modelem danych pełnym pobieraczy i ustawiaczy, ponieważ nie możesz w pełni reprezentować użytkownika w całym miejscu.

W firmie istnieją wyraźne granice, więc warto je modelować w ten sposób. Użytkownik logujący się w porównaniu z użytkownikiem systemu płac w porównaniu z użytkownikiem grającym w grę jest bardzo różny, nawet jeśli jest częścią tego samego systemu.

Myślenie w inny sposób - możesz teraz utworzyć kod zarządzania programistą, aby był bardzo lekki i niezależny od reszty systemu. Może się martwić o bardziej dokładne typy z mniejszym bagażem. Jest to krok do zbudowania mniejszych podsystemów, które mogą ostatecznie zostać wyodrębnione do własnej aplikacji.

Mogę dać ci inny przykład. Zastanów się, czy masz jakiś system e-commerce. Będziesz mieć tam produkty, jednak produkty będą należeć do co najmniej dwóch różnych domen:

• Katalog produktów, w którym przechowujesz opis produktu i wszystkie atrybuty
• Zapasy, w których masz poziom zapasów produktów

Jeśli masz jeden ograniczony kontekst dla obu domen, twoje rozwiązanie może szybko stać się wielką kulą błota, ponieważ zaczniesz odnosić się do niego. Na koniec nie będziesz już mieć dwóch domen. Twój spis produktów zostanie zepsuty z referencjami do katalogu produktów i odwrotnie. W rezultacie nie będziesz w stanie zmienić jednej domeny bez dotykania innej, nawet w pełni zdajesz sobie sprawę, że nie jest to wymagane. Twoje modele stają się od siebie zależne i ściśle powiązane, a także w zły sposób - zależne od implementacji.

Jeśli jednak masz dwa ograniczone konteksty, wszystkie zmiany dokonane w jednej domenie nie wpłyną na drugą, gdy tylko utrzymasz czyste kanały komunikacji. Oznacza to, że musisz mieć powielanie danych, ale jest to najmniejszy koszt płacenia za aplikację opartą na luźnych sprzężeniach. Twoje domeny mogą ze sobą rozmawiać za pomocą zdarzeń domenowych. Nawet jeśli na początku nie planujesz mieć aplikacji opartej na architekturze SOA, będziesz w stanie skalować się do tego poziomu, kiedy będziesz potrzebować przy stosunkowo niewielkim wysiłku, ponieważ po prostu zmienisz transport wydarzeń w domenie, pozostawiając ten pomysł bez zmian.

Aktualizacja: W SkillsMatter jest dobry przekaz umiejętności autorstwa Erica Evansa. Podaje analogię do starej historii, kiedy kilku niewidomych opisuje słonia z ich perspektywy. Ponieważ każdy człowiek może dotknąć tylko części słonia, opisują ją jako „drzewo”, „ścianę”, „węża”, „linę”. I każdy z tych ludzi ma rację w swoim kontekście. Ograniczony kontekst to miejsce, w którym żyje wszechobecny język. Poza kontekstem te terminy mogą mieć zupełnie inne znaczenie, ale w kontekście język jest taki sam w wielu domenach. Greg Young zdecydowanie zaleca rozpoczęcie czytania niebieskiej księgi z rozdziału 11, ponieważ tam wyjaśniono najważniejsze, podstawowe pojęcia. Skoncentrowanie się na wzorcach taktycznych na początku książki sprawia, że ​​to podejście „DDD-light” jest bardzo powszechne,