Konteksty i domeny związane z DDD?

16

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ą).

lko
źródło
Wydaje mi się, że jedyną rzeczą, która definiuje odrębne granice kontekstów, jest potrzeba różnicowania językoznawstwa i powiązanych różnic operacyjnych, tj. Nazywa się to produktem w jednym obszarze i produktem w innym obszarze, ale są one różne, więc potrzebujemy dwóch produktów i oba mogą ” t być w tym samym modelu (ta sama nazwa itp.). Dlaczego więc nie zmienimy nazw, aby reprezentowały ich subtelnie odmienną semantykę? Moglibyśmy mieć jeden model, by rządzić nimi wszystkimi. Subdomeny są naturalne, ale w tej chwili nie widzę ograniczonych kontekstów. Właśnie myślę tutaj głośno ...
Ashley Aitken
Wydaje mi się, że już zdałeś sobie sprawę, dlaczego opłaca się dzielić domenę na konteksty. Tym, co może się teraz przydać, jest właściwy sposób ich zidentyfikowania, zdefiniowania granic kontekstu. Oto jak to robię: medium.com/@wrong.about/…
Zapadlo

Odpowiedzi:

20

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.

Adrian Schneider
źródło
Dzięki za pomocniczy przykład, który pomaga zilustrować różne potrzeby 3 pne.
lko
Nie tak jestem przyzwyczajony do oglądania tych pojęć: Normalnie, Employeenie jest to User, że maUser . Jest Userto po prostu jednostka, za pomocą której osoba może się zalogować i uzyskać dostęp do jednej lub więcej aplikacji w organizacji. I Employeenie zawsze ma User. Ponadto zwykle nie otrzymujesz prostej aplikacji dla różnych działów; zazwyczaj każdy dział ma swoje własne aplikacje, z których każdy zawiera własne modele domen. Tak więc, dla mnie ta odpowiedź nie pomaga wyjaśnić potrzeby posiadania oddzielnych ograniczonych kontekstów w tej samej bazie kodu.
Rogério,
@ Rogério twój sprzeciw jest tak naprawdę pięknym przykładem na to, dlaczego ważne jest prawidłowe zdefiniowanie wszechobecnych języków używanych w każdym ograniczonym kontekście :)
MauganRa
Zastanawiam się tylko w przypadkach, gdy mamy system zarządzania klientami, kiedy dzwonimy w celu zapytania o nasze zamówienia, fakturowania itp. Zostajemy zawieszeni na czas przeniesienia do odpowiedniego działu. W grę wchodzi wiedza domena każdego działu - ku irytacji klienta w tych scenariuszach. Może możemy winić DDD za wymuszenie separacji między tymi kontekstami.
Andez
16

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,

Alexey Zimarev
źródło
1
+1 za wywołanie duplikacji. na początku jest to trochę mylące („Czy robię to źle ?!), ale jest całkowicie naturalne, w wielu przypadkach wymagane.
Adrian Schneider,
W tym scenariuszu, czy Productobie klasy hipotetycznie współużytkują ten sam identyfikator (np. Obie oddzielne tabele BC mają klucz obcy do tabeli z jednym identyfikatorem produktu)? Być może podczas komunikacji ze zdarzeniami domeny mogliby użyć tego identyfikatora?
lko
1
Wszystko zależy od wybranego magazynu. Nie jest konieczne używanie identyfikatora technicznego do odsyłania między domenami. Nie zaleca się także komunikacji między kontekstami.
Alexey Zimarev
1
Wygląda na to, że nadszedł czas, aby wyciągnąć niebieską książkę z półki i przeczytać późniejsze rozdziały
Markus Pscheidt,