Czy w usłudze DDD usługa domenowa jest w zasadzie tylko wzorem fasady i / lub mediatora?

W projektowaniu opartym na domenach warstwa domeny może mieć kilka (tradycyjnych) usług. Na przykład w domenie użytkownika możemy mieć:

UserFactory, który buduje obiekty użytkownika na różne sposoby
UserRepository, które jest odpowiedzialne za interakcję z usługami przetrwania w warstwie infrastruktury

Czy usługa użytkownika w warstwie domen jest po prostu mediatorem i / lub fasadą dla tych dwóch usług i warstwy infrastruktury, czy może jest coś więcej?

object-oriented object-oriented-design domain-driven-design

— e_i_pi
źródło

Zobacz także Usługi w DDD i Usługi w DDD

— Erik Eidt

Dużo czytałem posty na poziomie Gorodinski, ale nigdy nie widziałem tego drugiego linku. Świetna lektura, zdecydowanie dotyka niektórych ważnych punktów!

— e_i_pi,

Odpowiedzi:

Domain services najlepiej opisują to, czym nie są:

nie są EntitiesaniAggregate roots
oni nie są Value objects
posiadać wiedzę domenową, która naturalnie nie pasuje tylko do jednego Entity lub jednego Value object

Przykładem a Domain servicejest Saga/Process manager: koordynuje długotrwały proces obejmujący wiele Aggregate roots, możliwych z różnych Bounded contexts.

To powiedziawszy, co to jest Domain servicei jak jest realizowane to dwie ortogonalne rzeczy.

Czy usługa użytkownika w warstwie domen jest po prostu mediatorem i / lub fasadą dla tych dwóch usług i warstwy infrastruktury, czy może jest coś więcej?

Niektóre usługi domenowe, takie jak UserRepository(złożone z interfejsu zdefiniowanego w Domain layeroraz konkretnej implementacji w Infrastructure layer), mogą być zaimplementowane przy użyciu Facadewzorca projektowego. Inne usługi domenowe nie są.

Nie ma twardej zasady dotyczącej sposobu ich implementacji, oprócz ważnej zasady, że Domain layernie może zależeć od innych warstw (i SOLID ).

— Constantin Galbenu
źródło

Dziękuję, myślę, że w końcu rozumiem warstwę domeny. Oprócz przechowywania obiektów danych (agregatów, jednostek i obiektów wartości) zawiera także reguły biznesowe - ale nie konkretne wdrożenie tych reguł. Usługi domenowe określają, co można zrobić z obiektami danych domeny, ale nie mają wiedzy o tym, jak te operacje funkcjonują wewnętrznie.

— e_i_pi

Reguły biznesowe @e_i_pi są chronione tylko przez agregaty i ich zagnieżdżone jednostki. Usługi domenowe nie są w to zaangażowane.

— Constantin Galbenu,

@e_i_pi, gdzie operacja obejmuje więcej niż jeden agregat. Na przykład, biorąc pod uwagę listę kont bankowych (agregatów) osoby (innej agregacji), usługa domenowa obliczy całkowite saldo tych kont.

— Constantin Galbenu,

@e_i_pi: Myślę, że masz kilka nieporozumień. Cała warstwa domeny to model oprogramowania Twojej domeny. Powiedziałeś - „Oprócz przechowywania obiektów danych (agregatów, encji i obiektów wartości)” - nie są to „obiekty danych” w tym sensie, że po prostu przechowują dane; faktycznie wdrażają reguły domeny, określają zachowanie. Teraz Usługi domenowe według DDD książce E. Evans , są te aspekty dziedziny , które nie pasują naturalnie do obiektu (podmiotu lub przedmiotu wartości).

— Filip Milovanović,

Zamiast tego usługa domenowa „jest zdefiniowana wyłącznie pod względem tego, co może zrobić dla klienta”, zdefiniowana pod względem innych elementów modelu domeny (więc w jakiś sposób koordynuje te elementy i egzekwuje reguły domeny rządzące tą aranżacją). Sama usługa domenowa jest bezstanowa. Istnieje również koncepcja usług aplikacji , które znajdują się na warstwie wyższego poziomu i zasadniczo implementują historie użytkowników lub równoważne przypadki użycia, działając jako interfejs do warstwy domeny. Należy pamiętać, że stosunek obiektów do usług będzie się różnić w zależności od modelowanej domeny.

— Filip Milovanović,

Widzę usługi w DDD w wyniku odwrócenia zależności .

Jeśli użyjesz „zwykłych” zależności, kod domeny wywoła bazę danych w celu zapisania lub zapytania do encji lub fabryki, która tworzy encję powiązaną z bazą danych lub usługą zewnętrzną lub jakimś innym kodem infrastruktury.

Ale nie tak powinien wyglądać kod domeny. Kod domeny nie powinien zależeć od kodu infrastruktury. Ponieważ ta zależność utrudnia testowanie i ewentualnie ponowne użycie. Dlatego odwracasz tę zależność. Uzależniasz kod infrastruktury od kodu domeny. Aby to zrobić, musisz wprowadzić abstrakcję. Abstrakcja, która określa, jakie zachowanie kod domeny spodziewa się zaimplementować w infrastrukturze.

A usługi w DDD są tą abstrakcją. W większości przypadków w przypadku kodu domeny usługi te powinny być zwykłymi interfejsami. Implementacja powinna być zawarta w kodzie infrastruktury, który jest zależny od tych interfejsów.

— Euforyk
źródło

Dzięki za odpowiedź, obie odpowiedzi razem dały mi „aha!” za chwilę. Myślę, że bez twojej odpowiedzi nie do końca zrozumiałbym tę koncepcję, ale wolę odpowiedź Constantine'a jako wskaźnik dla przyszłych czytelników.

— e_i_pi,