Co rozumiem o domain-driven design

DD 101

Im większy projekt, tym trudniej go utrzymać. Sposobem na to jest rozbicie aplikacji na mniejsze obszary zgodnie z ich zasadami biznesowymi, zwanymi domenami.

Podstawowo, domena jest obszarem wiedzy, albo publicznej, jak zasady gry w szachy, albo prywatnej, jak zasady biznesowe organizacji non-profit.

Złożona domena prawdopodobnie będzie wykorzystywać wiedzę z innych domen. Na przykład organizacja non-profit, która uczy gry w szachy online, będzie wiedziała o szachach, nauczaniu za pośrednictwem platform internetowych, a także, nawet jeśli nie jesteś obciążany jako uczeń, o jej finansach.

Każda subdomena twojej domeny jest znana w DDD jako kontekst ograniczony, każdy ma swój własny model świata zbudowany z wyspecjalizowanych jednostek kodu, znanych jako bloki konstrukcyjne. Tutaj skupię się na encjach i obiektach wartości, do obu można się odwoływać jako do obiektów.

Encje są obiektami, które mają być unikalne w obrębie domeny. Osiąga się to poprzez użycie jednej lub więcej właściwości do identyfikacji danej encji. Na przykład, dwóch użytkowników używających tej samej nazwy w systemie zawsze będzie miało różne e-maile, ponieważ e-maile nie mogą się powtarzać – częściej niż nie, encje są rozróżniane przez id, a czasami przez kombinację własności.

Value-objects, z drugiej strony, nie mają tożsamości, więc tylko ich właściwości mogą być użyte do rozróżnienia dwóch instancji. Weźmy na przykład dwa pionki (żeton szachowy), wyglądają one tak samo, jeśli pochodzą z tego samego zestawu gier i mają ten sam kolor, więc nie ma znaczenia, jeśli je zamienisz. W DDD obiekty wartości są niezmienne, więc łatwiej jest z nimi rozumować.

Integralność danych

Kontekst ograniczony nie ujawnia wszystkich swoich obiektów, aby zagwarantować integralność danych. Zamiast tego, eksponuje niektóre korzenie agregatów jako rodzaj publicznego interfejsu do siebie.

An aggregate jest niczym więcej niż bytem, który jest złożony z innych obiektów. Mówiąc dokładniej, agregat jest skupiskiem powiązanych ze sobą obiektów, które przy zmianie danych traktujemy jako jednostkę.

W praktyce agregaty będą przyjmowały kształt struktury danych znanej jako drzewo. Z tego powodu, wszystkie agregaty mają korzeń.

Jedynym członkiem agregatu, do którego inne obiekty mogą się odnosić jest jego korzeń, i dlatego to właśnie go eksponujemy. Jest to zrobione w ten sposób, ponieważ zapobiega to innym obiektom do manipulowania danymi w sposób, którego agregat nie może kontrolować.

Ważne, aby wyjaśnić, że bounded context może używać wielu agregatów, nawet jeśli ich korzeń nie jest bezpośrednio wystawiony na świat zewnętrzny.

Realing with multiple bounded contexts

Ale rzeczy mogą stać się bardziej skomplikowane, prawda? Każdy ograniczony kontekst otrzymuje nieco inny model tych samych obiektów, posiadających różne właściwości i zachowania. Tak więc użytkownik w kontekście gry może mieć właściwość do obsługi jego wyniku, który w kontekście finansowym jest nieistotny, a zatem nie istnieje.

A to nie wszystko. Możliwe jest również, że pojęcie domeny, reprezentowane jako podmiot w ograniczonym kontekście, aby być reprezentowane jako obiekt-wartość w innym, lub po prostu być całkowicie pominięte.

Na przykład, podczas gdy kontekst nauczania wymaga, aby nauczyciele byli reprezentowani jako encje, aby mogli być przypisani do uczniów przez ich identyfikatory, kontekst finansów woli widzieć „nauczyciela” jako wartość dla właściwości position encji employee.

Kilka innych elementów składowych DDD to usługi, repozytoria, fabryki i zdarzenia. Postaram się je krótko opisać.

Usługi są możliwościami domeny, które nie pasują naturalnie do encji ani do wartości obiektów. Należy pamiętać, że są to usługi domenowe, a nie usługi aplikacji czy infrastruktury.

Repozytoria są pomostami do jednostek magazynowych – witaj CRUD!.

Fabryki są metodami tworzenia obiektów domenowych tak, aby nigdy nie miały nieprawidłowych wartości. Ta część jest tym, co sprawiło, że zacząłem myśleć o testach sterowanych produktem.

Wydarzenia są obiektami, które reprezentują coś, co wydarzyło się w domenie – jej eksperci dbają o nie. Świetne możliwości tworzenia aplikacji sterowanych zdarzeniami .

Chociaż nie pamiętam, aby Evans tak twierdził, ograniczone konteksty są miłą okazją do podzielenia twojego kodu na mikroserwisy, gdzie każda usługa jest kontekstem na własną rękę. Pierwszym krokiem może być „wirtualne” rozbicie, gdzie każdy kontekst jest umieszczony w innym module na tej samej aplikacji, a następnie, jeśli wykryjesz, że są naprawdę odizolowane, przenieś je do innych.

Język, aby rządzić nimi wszystkimi

Jedną z pierwszych rzeczy, których ludzie uczą się podczas studiowania DDD jest to, że ich system powinien być opisany przez wszechobecny język. Oznacza to, że powinniśmy pisać kod używając tych samych czasowników (dla metod lub usług) i rzeczowników (dla obiektów), których używają eksperci domeny, gdy z nami rozmawiają.

Pisanie kodu w ten sposób ma tę zaletę, że zamyka lukę komunikacyjną między programistami a ekspertami, gdy rozmawiają, ale jest to zbytnie uproszczenie prawdziwego życia, więc osobiście używam go jako wytycznej, ale nie jako ostatecznego rozwiązania.

Zachowałem to na koniec, bo dla mnie najważniejszej rzeczy o DDD zwykle nie czytam, bo jest w „skomplikowanej” części książki.

Ostatnio dowiedziałem się, że sam autor powiedział, że kolejność w jakiej przedstawia rzeczy w książce nie jest optymalna, a to co tu opisałem jest bliższe temu co byłoby idealne 😍. Usłyszałem to na podcaście nawiązującym do tego

.