Problem pojawia się gdy implementujemy funkcjonalności typu generacja faktury w pdfie dla klienta indywidualnego, taka czynność wykorzystuje (w kilku procentach) każdy obiekt z przedstawionych powyżej. Jednak przy jej tworzeniu przerost encji sprawia trudność w poruszaniu się po całym ekosystemie, problemy z wydajnością czy zbytnie powiązanie obiektów ze sobą.

Drugim przykładem jest użytkownik który może pełnić wiele ról jednocześnie (właściciel sklepu, kupujący – w 4 typach, użytkownik poczty, uczestnik programu partnerskiego etc.).
Można by w danym kontekście pracować na encji „użytkownik poczty” i mieć dostęp tylko do jego kontekstu gdyby nie fakt że dojdzie do scenariusza w którym użytkownik pełni 2-3 funkcje jednocześnie.

Co do zakwalifikowania Repozytoriów jako serwisy, wynika to z tego, że po pierwsze świadczą one usługi na rzecz klas domenowych, po drugie nie mają własnej tożsamości (nie są encjami), oraz atrybutów (nie są wartościami). Tak to wygląda z mojej perspektywy, jednak mogę się mylić

Ja się uczyłem, że serwisy powinny wykonywać logikę biznesową, która nie pasuje do żadnych z encji, stąd ich pełna nazwa „Domain Services” np.

$konto1->przelej(1000, $konto2); // przelewany 1000 dolców z rachunku 1 do rachunku 2

Z perspektywy „czystości” kodu jest ładnie i schludnie, ale z perspektywy eksperta dziedziny mamy wielkie WTF! – jak jedno konto może nadzorować przelew na drugie?

$przelewacz->przelej(1000, $konto1, $konto2); // przelewacz jest serwisem, nie encją

I już wszystko wróciło do normy.

Kiedyś na taką odpowiedź, od razu zapytałbym się „taaaaa, mądralo? A gdzie ja mam niby wysyłać maile, jak nie w serwisie, po np. zapisaniu encji?”. Podpowiem: „Domain Events”

Repozytoria natomiast są samodzielnymi i odrębnymi bytami (w świecie DDD), których zadaniem jest głównie perzystencja obiektów. Nie wtryniają się w logikę biznesową.

wynika to jednak z faktu, że oba rodzaje obiektów zwykle dostajemy gotowe w ramach jakiegoś frameworku lub innych bibliotek (Doctrine czy kontener DI).

1. Osobiście nigdy nie zastąpiłbym porządnej fabryki kontenerem IoC.
Aby lepiej zobrazować o co mi chodzi, zadam pytanie: Umiesz zastąpić buildera kontenerem? No właśnie nie bardzo – po prostu się nie da – a oba (builder i fabryka) robią to samo, tworzą obiekt, który jest na tyle skomplikowany, że nie wystarczy zwykłe new Object(); – z tym, że builder pozwala ingerować w sam proces tego tworzenia.
Fabryki są częścią infrastruktury i jako takie nie powinny być zastępowane czymś co pochodzi z warstwy aplikacji (a tam rezyduje kontener).

2. Warstwa dziedziny jest świadoma interfejsu warstwy infrastruktury. Dlatego ja zawsze tworzę w niej (w. dziedziny) przynajmniej interfejsy dla repozytoriów, fabryk i serwisów. Te interfejsy, mogą potem być implementowane w warstwie infrastruktury przez np. repozytoria oparte o Doctrine2, ale też własne klasy z obsługą PDO, etc. – nie polegam tylko na tym co dostarczają mi narzędzia.

Nadmienię, że kontenera IoC używam już jednak przy pobieraniu fabryk.

Natomiast uważam, że najistotniejszą rzeczą w całym DDD jest właściwe wymodelowanie klas encji i serwisów. Bez tego, projekt w ddd raczej nie ma szans na szczęśliwy finisz.

Dla mnie w idealnym projekcie DDD, dziedzina powinna być tak skończenie wymodelowana, że:
– Każdy kto spojrzy na diagram od razu wie o co „cho”
– Na podstawie implementacji kodu z tego diagramu można zbudować cała infrastrukturę (stąd te interfejsy)

Kończę właśnie aplikację do pracy dyplomowej – mały project manager – w którym, aby udowodnić tą tezę: warstwa dziedziny jest zupełnie innym projektem (logicznie: eer, bo jest warstwą dziedziny; fizycznie: mieści się w zupełnie innym repozytorium GIT). Cała warstwę infrastruktury mam już wewnątrz projektu głównej aplikacji (Symfony2 + Doctrine2).

P.S. Skasuj poprzedni post ;P Zrobiłem mały edit, żeby lepiej się czytało.

Mimo wszystko potraktowałeś je (repozytoria) bardzo po łebkach oraz nie mogę się z Tobą zgodzić, że repozytoria są serwisami.

….ale jak mogłeś nie wspomnieć nic o repozytoriach (i ewentualnie o fabrykach), które odgrywają tak duża rolę w faktycznym podziale dziedzina-infrastruktura?