Domain Driven Design, niewątpliwie, to jeden z modniejszych tematów nowoczesnego programowania. Znalazł swoje miejsce również w ekosystemie PHP. Aktualnie, wiele aplikacji powstaje w oparciu o to podejście. Jak to zrobić? Lista tematów do ogarnięcia jest dość szeroka. O ile powstała cała masa materiałów teoretycznych, o tyle z praktyką jest trochę gorzej. Dużo mówi się o samej domenie, a więc sensowne przykłady związane z tą warstwą jeszcze da się znaleźć. To zrozumiałe, skoro właśnie tego dotyczy DDD.
Na koniec dnia, mimo wszystko, model musi mieć swoją reprezentację w infrastrukturze.
Innymi słowy, dane muszą zostać utrwalone. Błędne założenia na tym poziomie także potrafią zepsuć aplikację. Pozostaje wtedy pochwalić się w CV świetnie wydzieloną domeną, nie wspominając nic o tym, iż aplikacja nie działa i jest do zaorania. Wystarczające, by dostać nową pracę.
Mimo wszystko, temat jest ważny, więc postanowiłem go podjąć. Miałem przyjemność brać udział w kilku projektach, gdzie domena grała pierwsze skrzypce. To pozwoliło mi wypracować dwie rozsądne opcje na pospawanie tego z warstwą infrastruktury. Zanim udało mi się do nich dojść, wielokrotnie miałem naświetlone oczy. Tak kończy się spawanie bez okularów. Oczywiście, nie jest tak, iż są to innowacyjne pomysły. Obstawiam, iż wielu z Was robi to w podobny sposób.
Każdy projekt ma swoje uwarunkowania techniczne. W tym materiale zakładam, iż głównym źródłem danych jest baza relacyjna, a do persystencji wykorzystywane jest najpopularniejsze narzędzie mapowania obiektowo-relacyjnego w PHP. Wydaje mi się, iż wciąż będzie to bardzo częsta konfiguracja.
Jak wspomniałem, wyróżniam dwa sposoby persystencji obiektów domenowych w PHP przy użyciu Doctrine ORM. Jedno trochę mniej radykalne i szybsze w implementacji, a drugie bardziej elastyczne, ale czasochłonne. Postaram się kompleksowo zdefiniować oba, porównać je i pokazać na realnych przykładach. Na samym początku zaznaczę, iż jedno i drugie są dla mnie w pełni akceptowalne. Koniec tego przydługiego wstępu – do kodu!
Obiekty domenowe jako encje Doctrine
To podejście wydaje się bardzo naturalne. Ucząc się programowania, na samym początku, przyświeca jeden fundamentalny cel – ma działać. Bierze się ORM, tworzy się encje w zgodzie z dokumentacją, czy poradnikiem i śmiga. No, przynajmniej powinno. Kolejnym etapem jest próba poznania i wprowadzenia w życie dobrych praktyk. Okazuje się, iż model do tej pory to zwykły worek na dane. Tak zwany model anemiczny. W programowaniu obiektowym istotne są również zachowania, które pozwalają sterować danymi. Tak zwany bogaty model, który wyraża intencje biznesowe. Zamiast trzymać logikę w tak zwanych serwisach, przenosi się poszczególne funkcje do modelu. Taki zabieg pozwala wprowadzić adekwatną enkapsulację. Na tym etapie jest już naprawdę nieźle i dla części projektów wystarczająco.
Następny krok to bardziej zaawansowana architektura. Jak sprawić, żeby kod był łatwiej rozwijalny, eksponował faktycznie najistotniejsze elementy aplikacji i gwarantował ogólnie pojętą jakość. Opcji jest oczywiście kilka, ale jednym z ważnych elementów jest odseparowanie domeny od świata zewnętrznego. To pozwoli łatwiej trzymać ją w ryzach, a co za tym idzie rozwijać niezależnie.
Czy model, który udało się wypracować do tego momentu spełnia to założenie? Trzeba inaczej zadać pytanie. Czy baza danych albo ORM, jakkolwiek, mają wpływ na domenę? Odpowiedź jest następująca: tak. Niestety. Czy jest to problematyczne? W moim odczuciu, wpływ ten wydaje się niewielki i jest akceptowalny. Do tego przejdę zaraz, ale najpierw przykładowy model i jego mapowanie.
Warstwa domeny
Czy ten model można uznać jako zanieczyszczony? Zależy jak bardzo purystycznie podchodzi się do tematu. Generalnie, z infrastruktury pochodzą dwie zależności: klasa \DateTimeImmutable oraz atrybuty (we wcześniejszych wersjach adnotacje).
Ogólnie, uważam iż konstrukcji językowych można spokojnie używać w modelu domenowym. Inne spojrzenie doprowadzi to do tego, iż model domenowy będzie wyrażany w agnostycznej technologii jak JSON, czy YAML – bez sensu. Takie skrajności nie są niczym dobrym. W zgodzie z tym założeniem własne wyjątki domenowe mogą dziedziczyć po klasie \Exception, a obiekty typu \DateTime są mile widziane. Pomijając fakt, iż czasem wprowadzenie własnego obiektu wartości reprezentującego date może dać wartość. Szczególnie jeżeli będzie on potrzebował niestandardowych reguł i zachowań.
Co z mapowaniem w obiektach domenowych? Klapki na oczy i nie widzę przeszkód. o ile decyzja należy do mnie to, mimo wszystko, wynoszę mapowanie do konfiguracji korzystając z XML. Przyznam, iż kiedyś byłem do tego sceptycznie nastawiony. Okazało się, iż mapowanie w XML tworzy się naprawdę łatwo i przyjemnie. Obiekty domenowe są bardziej przejrzyste, bo atrybuty i adnotacje potrafią zaśmiecić sedno modelu. Już choćby nie wchodząc w kwestie, iż zależności z infrastruktury infekują domenę. Nie jest to szkodliwy rodzaj zanieczyszczenia.
Ważniejsza kwestia to wpływ mapowania na strukturę obiektu. Faktycznie, chociażby obiekt PaymentId jest wewnątrz trzymany jako pole typu string . Spłaszczanie obiektów na potrzeby persystencji to też całkiem sensowny zabieg. Dzięki enkapsulacji ta informacja i tak nie wycieka na zewnątrz. przez cały czas wszystkie operacje wykonywane są na obiektach. Jest kilka alternatyw:
- własny typ (Doctrine jest łatwo rozszerzalny, ale mając własny identyfikator w każdej encji, robi się tego całkiem sporo);
- używanie Embeddables jako typów (bardzo fajnie się sprawdza dla obiektów wartości, chociaż raczej nie jako identyfikator);
- popularna biblioteka ramsey/uuid dostarcza własny typ (wtedy mowa o jednym typie identyfikatora dla wszystkich encji oraz zezwolenie na wyjątek, bo typ pochodzi z warstwy infrastruktury).
Faktycznie, widać tu wpływ persystencji na dziedzinę. Z drugiej strony, jest dużo opcji na robienie tego niezależnie, a tworzenie własnych typów pozwoli zrobić niemalże wszystko. Ale kiedy mowa o niezależności to warto wspomnieć, iż przy tym podejściu trzeba mieć to na uwadze.
Istnieje inna zależność, której nie widać w przykładzie, a jest to częsty przypadek. Chodzi o kolekcje. Przy relacjach jeden-do-wielu i wiele-do-wielu trzeba używać dedykowanych kolekcji Doctrine. Przy tworzeniu jest to instancja Doctrine\Common\Collections\ArrayCollection, a przy odtwarzaniu Doctrine\ORM\PersistentCollection. Obie spięte interfejsem Doctrine\Common\Collections\Collection. Doctrine nie pozwala na własne kolekcje i trzeba zezwolić na takie ustępstwo. To już bez wątpienia jest infekcja domeny, chociaż w razie potrzeby łatwo ją wymienić. Pochodzi z osobnej paczki i nie trzeba dociągać całego ORM, żeby móc z niej korzystać. Traktowałbym to jako taka kolekcja zewnętrzna. Mimo wszystko, ograniczenie istnieje, bo nie ma możliwości implementacji kolekcji na własną rękę.
Niestety, dużo rzadziej w tym podejściu można postawić na łatwą relację wiele-do-jednego, gdyż to z poziomu agregatu będzie zarządzanie kolekcją. W tym wypadku trzeba mieć relację dwukierunkową, a tutaj niepotrzebnie rośnie stopień skomplikowania. I o ile w niektórych miejscach jest to naturalne, o tyle tutaj mowa o każdej takiej relacji.
Poniżej prezentuję pozostałą część modelu, gdzie mapowanie pozostało w obiekcie wartości Amount. Wykorzystany został typ Embeddable. Doctrine pozwala też w łatwy sposób odtwarzać typy Enum, więc nie potrzeba dedykowanego typu, co widać na załączonym obrazku.
Model płatności gotowy, ale brakuje interfejsu repozytorium. To również część domenowa. Ta warstwa wie, iż gdzieś utrwala i skądś odczytuje stan. Nie interesują jej szczegóły, dlatego konkretna implementacja repozytorium trafi już do infrastruktury i tam oprze się o Doctrine ORM. Repozytorium bardzo często posiada tylko dwie metody: save() i get(), ale nic nie stoi na przeszkodzie, żeby dokładać kolejne.
Warstwa infrastruktury
Repozytorium opiera się o Entity Manager (publiczny interfejs ORM) i encje domenowe, które równocześnie są encjami Doctrine. Jest to całkiem przejrzyste podejście. W tym przykładzie nie ma relacji, ale trzeba pamiętać, iż narzędzie to domyślnie używa mechanizmu lazy loading. Agregaty, o ile są adekwatnie skonstruowane, raczej powinny być odczytywane w całości. Warto pokusić się o strategię fetch eager, czyli dociąganie oryginalnych encji od razu. Raczej nie na poziomie encji, a na poziomie konretnego zapytania. I tak tutaj nie użyłbym metody find() a po prostu własne zapytanie z addSelect(). Dzięki temu zredukuje się liczbę dodatkowych zapytań.
W swoim założeniu lazy loading jest genialny. Mało będzie przypadków, gdzie agregat powinien być wczytany tylko częściowo. Do odczytu nie wykorzystuje się modelu domenowego. Jak wspomniałem, agregat z dobrymi granicami ma dokładnie te pola i zachowania, których potrzebuje i zawsze ładowany jest w całości. Gdyby jednak tworzyć model po prostu jako encje, nie jako agregaty, to lazy loading może się sprawdzić. Nie warto wczytywać całego obiektu, o ile akurat w tej konkretnej operacji nie są potrzebne obiekty zależne.
Warstwa aplikacji
Na sam koniec, warstwa aplikacji i przykładowy serwis pozwalający na podstawie komendy utworzyć nową płatność. W zasadzie, wystarczy go wpiąć to w kontroler i tak wygląda pełny cykl od momentu żądania użytkownika do momentu utrwalenia danych w bazie.
Doctrine – mapowanie w XML
Tak jak wspomniałem, warto pomyśleć o wyciągnięciu mapowania do plików konfiguracyjnych XML. Pozwoli to zachować bardziej czytelne obiekty domenowe. Zgadzam się, iż mapowanie jest delikatnie toporniejsze, ale z początku i tak myślałem, iż jest to mniej przyjemne. Poza tym zamyka się dyskusja purystyczna, czy można używać adnotacji w domenie. Chociaż tak jak mówię, nie jest to kwestia o którą bym się zabijał. Dla mnie adnotacje w domenie są akceptowalne.
Poniżej dokładnie ta sama klasa Payment , ale już bez atrybutów. Mapowanie zostało przeniesione do infrastruktury lub konfiguracji projektu w oparciu o XML. Dla mnie takie klasy są bardziej przejrzyste, więc w tę stronę bym szedł, ale wiem iż jest opór po stronie wielu programistów. Pojawiają się argumenty, iż łatwiej zmieniać w jednym miejscu i tym podobne. Nie dyskutuję z tym.
Tak przygotowany model domenowy to cześć tylko i wyłącznie modelu zapisu. Odczyty powinny bazować na osobnym modelu. Oczywiście, można tworzyć zapytania używając DQL i Query Builder, ale rezultat nie powinien być hydrowany do encji, tylko do bardziej suchej postaci: DTO lub tablica. Te metody nie powinny znajdować się w repozytorium, które jest domenowe, a w osobynch klasach reprezentujących zapytania lub ewentualnie repozytorium odczytowym. Jest to bardzo istotne, bo mając pomieszane encje infrastrukturalne z encjami domenowymi może istnieć pokusa dalszego mieszania warstw.
Czas na podsumowanie tego rozwiązania. Czy to podejście ma rację bytu? Zdecydowanie tak. Po to korzysta się z ORM, żeby zwiększyć produktywność i łatwość dostarczania. Twórcy Doctrine naprawdę ograniczyli do minimum wpływ swojej biblioteki na model, dzięki temu, iż oparli ją o wzorzec Data Mapper. Nie korzysta ona konstruktorów, czy getterów/setterów a pod spodem wykorzystuje mechanizm refleksji. Powoduje to, iż można tworzyć całkiem niezależne modele. Mimo wszystko, nie jest to najwyższy poziom elastyczności i niezależności. W wielu projektach wystarczający i akceptowalny. Każde inne rozwiązanie wymaga dużo więcej pracy.
W taki sposób często tworzy się aplikacje w Symfony. Aktualnie równie znany jest Laravel. Z uwagi na jego popularność równie szeroko wykorzystywany jest Eloquent. Korzystając z tego narzędzia taki model domenowy jest niemożliwy do osiągnięcia. Stoi za nim Active Record, a więc klasy reprezentujące model są tak naprawdę reprezentacją rekordów z tabeli w bazie danych. Jest to tak mocno powiązane, iż nie mowy o niezależności, a baza danych wymusza strukturę modelu. W takim układzie lepiej sprawdzi się podejście numer dwa. Stosuje się je także przy Doctrine dla bardziej rozbudowanych aplikacji.
Separacja modeli i transformacja
Ten koncept opiera się na transformacji modelu domenowego na model infrastrukturalny i w drugą stronę. Mechanizm ten daje więcej możliwości, ale niestety oczekuje dużego nakładu pracy. Na czym polega elastyczność? Obiekty domenowe da się odtworzyć z każdego źródła. Niemalże z kartki papieru. Zauważcie, iż w tym artykule mowa o relacyjnych bazach danych. Bywa, iż może być potrzeba odtworzenia stanu agregatu z baz typu NoSQL albo zdarzeń w podejściu Event Sourcing.
Warstwa domeny
Powyżej model obiektu płatności, który został zmodyfikowany o potrzebne zmiany. Przydadzą się dwie metody: create() i restore(). Jedna do tworzenia obiektu, a druga do odtwarzania istniejącego. Wcześniej nie było to konieczne, bo jak wspomniałem Doctrine potrafi je odtwarzać w oparciu o refleksję. Gdyby wykorzystać poprzedni model to przy każdym odczytaniu z bazy danych emitowane byłoby zdarzenie o utworzeniu płatności, a status byłby ustawiany na oczekujący. I dlatego warto skorzystać z tak zwanych named constructors, czyli metod statycznych pozwalających utworzyć obiekty w różnych przypadkach. W tym podejściu konstruktor powinien być prywatny, co zablokuje możliwość stworzenia obiektu przez operator new.
Ostatnia z różnic, to gettery. Żeby przetransformować obiekty, trzeba mieć możliwość odczytania stanu obiektu. Można spotkać się z opinią, iż jest to niewłaściwe. Wycieka stan agregatów na zewnątrz. Jest w tym trochę racji, ale nieszczęsną alternatywą jest tworzenie tak zwanych snapshotów. Tak naprawdę jest to implementacja wzorca Memento. Na papierze rozwiązanie świetne. W praktyce kolejny obiekt trzymający tę samą strukturę. Transformery to i tak już spory narzut i dodanie nowego pola powoduje, iż trzeba przewalić się przez kilka warstw i dokonać modyfikacji w wielu plikach. Dodanie migawek to moim zdaniem przerost formy nad treścią. Mniej bolą mnie te gettery. Ich rozsądne używanie nie powinno stanowić problemu. Ponadto ułatwią testowanie stanu agregatu, więc dwie pieczenie na jednym ogniu. Bardziej niebezpieczne bywają settery, gdzie można wprowadzić obiekt w niespójność, ale tutaj też da się pilnować stanu. Na szczęście dzięki metodzie restore() nie ma potrzeby setterów.
Z drugiej strony, nie ma gwarancji iż ktoś nie użyje metody restore() zamiast create(). Tak samo można użyć refleksji, czy po prostu dokonać zmian w kodzie. Chodzi o to, żeby publiczny interfejs był klarowny i jasno określał swoje przeznaczenie. A bez wątpienia tu ma to miejsce. Reszta modelu nie różni się w żaden sposób na tym etapie, ale wklejam je dla kompletności i przejrzystości.
Warstwa infrastruktury
Trochę więcej będzie się działo w samej infrastrukturze. Po pierwsze, trzeba stworzyć encję Doctrine. Własności tej klasy polami przypominają wcześniejszy model. Nie ma jednak zachowań i jest to całkowicie anemiczna klasa z getterami i setterami. W zasadzie obeszłoby się też bez konstruktora, ale pilnuje on, czy wszystkie wymagane pola zostały ustawione. Tutaj nie ma też mapowania na typy Enum, a obiekt Amount został spłaszczony.
Do tego potrzebne będzie repozytorium Doctrine. Tym razem takie, które potrafi operować na encjach infrastrukturalnych. Teoretycznie to repozytorium mogłoby być wykorzystywane także do modelu odczytu. W tym podejściu model odczytu można oprzeć o encje. Oczywiście, nie rekomenduję takiego podejścia. Dla przyspieszenia prac i łatwości utrzymania może mieć to sens. Ale istnieje ryzyko, iż ktoś zmodyfikuje stan encji w operacji odczytu. Chociaż mam nadzieje, iż to nieporozumienie, które nie ma miejsca. Zdecydowanie lepsze okaże się wyciągnięcie encji w zapytaniu, ale ostatecznie przetransformowanie i zwrócenie obiektów DTO, czy tablic. Mając taki kontrakt, dzięki odpowiedniej enkapsulacji, w zasadzie nie jest istotne, co jest wewnątrz. Część prostych zapytań może oprzeć się o encje, a inne mogą być hydrowane do tablic. Te najbardziej wymagające mogą być choćby czystymi zapytania SQL.
To temat na inny materiał, ale wspominam o tym, bo to daje elastyczność osobnego modelu odczytu i zapisu. W dużym skrócie, chodzi o to by nie hydrować niepotrzebnie do encji, gdzie sama operacja jest kosztowna, a jeszcze Doctrine dodatkowo śledzi te obiekty i trzyma w pamięci. Wystarczające i bardziej efektywne będzie hydrowanie do tablic. Tak samo, jak w pierwszym podejściu będzie to lepsze rozwiązanie. W przypadku wspólnego modelu dla encji i domeny, opieranie na nim modelu odczytu też wymagało by dodania getterów, ale jak wspomniałem – nie rekomenduję.
I bohater tego podejścia, czyli transformer. Jego zadaniem jest tłumaczenie encji na model domenowy i odwrotnie. Zawiera dwie metody fromDomain() i toDomain(). Generalnie, przykładowy transformer nie ma raczej nic skomplikowanego. Są to proste w konstrukcji klasy. Trochę więcej roboty będzie w przypadku obiektów drzewiastych. Wówczas potrzeba będzie wstrzyknąć kilka repozytoriów i znaleźć też powiązane obiekty, a jeżeli nie istnieją to je utworzyć.
Zapis warto zrobić to ramach opcji cascade persist, bo przecież agregaty są utrwalane w całości. Rzecz, o którą również trzeba zadbać to problem n+1. Przy samej transformacji, o ile istnieje wiele elementów potrzebnych do kolekcji to lepiej wyciągnąć je wszystkie w ramach jednego zapytania. Zamiast każdy osobno wewnątrz pętli. W sumie, o ile pola w modelu domenowym są nieedytowalne to nie trzeba ich uwzględniać w transformacji. W razie potrzeby zawsze można rozszerzyć.
Finalnie, implementacja repozytorium domenowego działa w oparciu o repozytorium Doctrine i transformer. Taki zestaw pozwala dość elastycznie zarządzać modelem. Poniżej po raz kolejny kwestia wywołania tej części kodu w warstwie aplikacji. Niemalże to samo, co poprzednio. Jedyna różnica to inny mechanizm wytwarzania samej płatności.
Warstwa aplikacji
Podsumowując, ten mechanizm jest naprawdę elastyczny. Jest to pewna inwestycja, która może się zwrócić – ale nie musi. Nie ma tutaj mowy o jakimkolwiek wpływie persystencji na domenę. Można zapisywać dane choćby jako JSON, nie trzeba tworzyć własnych typów, używać Embeddables i tak dalej.
Skoro i tak samodzielnie trzeba przetłumaczyć obiekty, to po co ORM…
Nie jest tak, iż Unit of Work i Identity Map tracą tutaj swoją funkcjonalność. Sam mechanizm śledzenia zmian, transakcji w pamięci i buforowania w pamięci też oddaje. Doctrine zagwarantuje, iż nie trzeba dwa razy odpytywać bazy o ten sam obiekt, ale też wykona tylko potrzebne zapytania aktualizujące. Rozpoznawanie, co się zmieniło w danym obiekcie nie jest takie łatwe. Implementacja tego na własną rękę to także sporo pracy. Najprościej byłoby zawsze nadpisywać cały obiekt, ale znowu – po co jeżeli nie dokonano żadnej zmiany albo dokonano tylko częściowej. Poza tym Doctrine przyda się też do modelu odczytu, dobrze zarządza połączeniem i kilka innych bajerów. Gdyby była potrzeba persystencji któregoś agregatu w oparciu o czyste zapytania SQL to też nie widzę problemu, ale nie jest to taki częsty przypadek. Raczej wchodzą tutaj w grę kwestie wydajnościowe, które dla pojedynczych obiektów nie powinny mieć znaczenia.
Rzecz warta wspomnienia to kwestia modularyzacji. Na samym początku, częstym sposobem integracji jest baza danych. Ma to swoje plusy i minusy, ale na pewno jest jednym z prostszych sposobów integracji – stąd też ochoczo wybieranym. Mając transformery można w prosty sposób czytać choćby z tych samych tabel dla innych agregatów. Zauważcie, iż w przypadku podejścia pierwszego jest to niemożliwe, bo z jednej tabeli nie da się odtwarzać wielu encji. Nie twierdzę, iż jest to dobra praktyka, ale na pewnym etapie może fajnie podnieść produktywność.
Jasne, wiele agregatów z tej samej tabeli może skończyć się porażką. Na przykład o ile mowa o dostępie do danych i ich potencjalnemu nadpisywaniu. W praktyce ratuje przed pewną replikacją danych, co wiąże się z bardziej skomplikowanymi mechanizmami jak asynchroniczne przetwarzanie zdarzeń i spójność ostateczna. o ile każdy agregat ma swoją niezależną reprezentację w bazie danych to idealnie. Znowu wymaga pewnej gimnastyki, która może się okazać zbyteczna dla wielu projektów. Modularność na poziomie logicznym, czyli w kodzie to i tak już duży sukces. Moduły reprezentują konkretne jednostki dziedzinowe i model jest dużo bardziej adekwatny. Nie jest świadom, w jaki sposób jest persystowany. Co jest elastyczne, ale oczywiście trzeba mieć na uwadze, iż istnieją ukryte sprzężenia właśnie w postaci bazy danych. Kiedy coś jest niejawne to potrafi się zemścić. Trzeba uważać. Fakt jest taki, iż w dzisiejszym programowaniu źródła danych traktuje się bardziej jako magazyn danych. Nie ma tam miejsca na żadną logikę, a większość ograniczeń realizowanych jest na poziomie kodu.
Na co postawić?
Podejście z transformerami pozwala na dużo więcej, ale ma dodatkowy narzut. Sam do końca nie jestem przekonany, czy jest to zasadne. Mimo, iż z powodzeniem stosuję także to podejście. Gdyby nie Doctrine i jego Data Mapper to w zasadzie nie ma dyskusji. Byłaby to jedyna sensowna opcja na reprezentację bogatej domeny. Ale Doctrine pozwala na prawie całkowite odseparowanie kwestii persystencji. I naprawdę, dla dużej części projektów okaże się to wystarczające. Bardziej należy skupić się na samym odkrywaniu i modelowaniu domeny, niż na kwestii utrwalania.
Dodatkowo, wychodząc od wspólnego modelu, nie jest powiedziane, iż nie da się w trakcie życia aplikacji przerzucić na podejście z transformerami. W wielu projektach może sprawdzić się sensowne podejście hybrydowe. Może jest tak, iż część agregatów jest odtwarzanych ze zdarzeń, część z encji Doctrine, a pozostała część operacji jest mocno CRUD i modyfikacje występują bezpośrednio w warstwie infrastruktury. Tak byłoby idealnie, ale to wiąże się z szerokim rozumieniem kilku podejść, a często chce się dążyć do spójności. choćby kosztem trochę gorszego dopasowania rozwiązania do problemu.
Moim zdaniem oba rozwiązania są legitne. Ostatnio częściej pracuję z transformerami, ale nie jest to mój pierwszy wybór. To podejście ma spory narzut, a tak naprawdę zamyka mordy teoretykom. Jasne, płynie z tego wartość, co starałem się pokazać. Czy na tyle duża, iż warto ponieść koszt? W większości projektów wyjście od modelu domenowego z mapowaniem będzie dobrym pomysłem. Wystarczy się przeprosić z kilkoma zależnościami, które w mojej opinii nie są tragiczne i nie warto walczyć o ich eliminację. Prawda jest taka, iż transformery, w większości przypadków, mając już doświadczenie, pisze się w 5 minut. Tylko powielanie wielu tych pól w kilku miejscach jest uciążliwe. Zresztą jak każda próba wprowadzenia niezależności i dokładania kolejnych warstw.
W wielu aplikacjach widzę dużo większe problemy związane z całym DDD i ogólnie pojętą architekturą. Warto najpierw skupić się na adekwatnym modelowaniu, a dopiero potem na persystencji. Mimo wszystko, nie można odpuścić tego zagadnienia. Chciałem pokazać dwie popularne opcje, tak żeby rzucić trochę światła od tej strony. Jak powiedziałem, na koniec dnia nawet najlepszy model bez persystencji nie ma racji bytu.
Wpis Persystencja obiektów domenowych z Doctrine ORM pojawił się pierwszy raz pod Koddlo.
