GoldenLine
Zaloguj się
Adrian C.

Adrian C.
projektant/programis
ta

Temat: [DDD]Fasada czy może warstwa aplikacji.

Witam, ostatnimi czasy próbuje stworzyć sobie mini projekcik zgodnie z wytycznymi DDD.
Cała domenę mam już praktycznie zaimplementowaną. Jestem obecnie na etapie tworzenia warstwy aplikacji. Warstwa ta będzie implementacją poszczególnych use casów z nałożoną tranzakcyjnością i regułami bezpieczeństwa. Do tego chcę stworzyć interfejs webowy(widok). Do widoku nie chcę przepychać encji domenowych, warstwa widoku będzie współpracowała z obiektami DTO. Pytanie moje brzmi następująco:
Czy warto zainwestować czas w zaimplementowanie nowej warstwy nazwijmy to fasada, która będzie miała zestaw obiektów DTO widokowych dla konkretnego widoku, oraz obiektów zajmujących się tłumaczeniem encji biznesowych na DTO, czy może z warstwy aplikacji wypluwać gotowe DTO, i założyć że każdy interfejs dostosuje się do DTO. Wtedy warstwa aplikacji będzie tłumaczem DO<->DTO.
Zdaję sobie sprawę z plusów i minusów obu rozwiązań, chciałem poznać waszą opinię, bo tj. wspomniałem dopiero raczkuję w temacie.
Link do wypowiedziLink
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: [DDD]Fasada czy może warstwa aplikacji.

Poczytaj o context boundaries i pamiętaj, że nie warto tłumaczyć encji na DTO, lepiej od razu zasilać danymi bezpośrednio w repozytoriach/serwisach.
Link do wypowiedziLink
Adrian C.

Adrian C.
projektant/programis
ta

Temat: [DDD]Fasada czy może warstwa aplikacji.

Alan Gabriel B.:
Poczytaj o context boundaries i pamiętaj, że nie warto tłumaczyć encji na DTO, lepiej od razu zasilać danymi bezpośrednio w repozytoriach/serwisach.

Wybacz ale nie zrozumiałem, co oznacza, że lepiej od razu zasilać danymi bezpośrednio w repozytoriach/serwisach.
Link do wypowiedziLink
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: [DDD]Fasada czy może warstwa aplikacji.

Adrian Chrzastowski:
Wybacz ale nie zrozumiałem, co oznacza, że lepiej od razu zasilać danymi bezpośrednio w repozytoriach/serwisach.

Nie przepakowuj encji do dto, pobieraj dane od razu w postaci dto. Taki był mniej więcej zamysł.
Link do wypowiedziLink
Jacek Hełka

Jacek Hełka CCA Europe.pl Sp. z
o. o.

Temat: [DDD]Fasada czy może warstwa aplikacji.

Wydaje mi się, że całkowite zastąpienie DO przez DTO będzie niezgodne z duchem DDD, choć, moim zdaniem, jest to rozwiązanie zdrowe i pragmatyczne. Bardziej DDD byłoby chyba przeciąganie encji do UI, bez pośrednictwa DTO.

Jeśli chcesz stworzyć coś bardzo DDD, to stosuj DTO tylko tam, gdzie dostęp do danych jest zdalny (albo jest bardzo prawdopodobne, że będzie zdalny).

Z drugiej strony, jeżeli będziesz od razu tworzył DTO w serwisach, to
- albo będą musiały dostarczać danych na potrzeby konkretnych use case-ów,
- albo będą miały taką samą strukturę, jak encje, a wtedy trzeba je będzie łączyć w większe grupy, żeby posłać wyżej (czyli dane określonej encji + różne dane słownikowe do edycji + kilka DTO obiektów powiązanych, itd).
Przy pierwszym serwisy stracą wiele ze swej ogólności, przy drugim okaże się często, że dane odzwierciedlające zawartość informacyjną encji są niewygodne i najlepiej je w coś przepakować.

Z dwojga złego bardziej sensowne wydaje mi się pierwsze podejście.
Link do wypowiedziLink
Adrian C.

Adrian C.
projektant/programis
ta

Temat: [DDD]Fasada czy może warstwa aplikacji.

Dzięki wszystkim za podpowiedzi.

Jacek DO w UI to same problemy :)

Im dłużej kombinuje, tym bardziej jestem skłonny rozwiązać to w sposób następujący.
Warstwa fasady, o której mówiłem wcześniej podzielona będzie na część odpowiedzialną za pytania i w tej części przepakowanie DTO->DO nie będzie miało miejsca, DTO będę wyciągał z boku pewnie bezpośrednio z DAL(warstwy dostępu do danych) przy użyciu nazwijmy to Finder'ów, oraz na część odpowiedzialną za przekazywanie rozkazów do warstwy aplikacji.
Warstwa aplikacji jako parametr rozkazu przyjmie DTO(tj. pisał Jacek będzie to DTO na potrzeby konkretnego use case'a), co niestety wymusi istnienie klas DTO w warstwie aplikacji. Do tych klas DTO, będzie musiał dostosowywać się każdy interfejs, czy to web czy jakiś inny. Co wy na to?
Link do wypowiedziLink
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: [DDD]Fasada czy może warstwa aplikacji.

Jeżeli to nie jest tajne, to może podzieliłbyś się jakimś diagramem UML, mam wrażenie, że polepszyło by rozumienie meritum tematu przez interlokutorów i zaproponowanie odpowiedniego rozwiązania ;)
Link do wypowiedziLink
Jacek Hełka

Jacek Hełka CCA Europe.pl Sp. z
o. o.

Temat: [DDD]Fasada czy może warstwa aplikacji.

Nasuwa się pytanie, czy warto w tym momencie w ogóle mieć DO, a przynajmniej, czy warto, żeby to były "mądre", bogate w funkcjonalność obiekty?
Przepakowywanie ich później w DTO na potrzeby edycji wydaje mi się raczej uciążliwe - coś jak kopanie rowów.
Może lepiej wszystko już robić na DTO, tak jak proponował Alan.
Wprawdzie to już rezygnacja z podstawowego elementu DDD, z drugiej jednak strony prosta, pragmatyczna, rozsądna architektura.

Z dwojga złego...
Link do wypowiedziLink
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: [DDD]Fasada czy może warstwa aplikacji.

Jacek Hełka:
Nasuwa się pytanie, czy warto w tym momencie w ogóle mieć DO, a przynajmniej, czy warto, żeby to były "mądre", bogate w funkcjonalność obiekty?
Przepakowywanie ich później w DTO na potrzeby edycji wydaje mi się raczej uciążliwe - coś jak kopanie rowów.
Może lepiej wszystko już robić na DTO, tak jak proponował Alan.

Nic takiego nie proponowałem. Anemiczne modele to zło.
Twierdzę tylko, że - o ile soft na to pozwala (Hibernate pozwala) to - lepiej jest pominąć etap "przepakowywania" i pobierać od razu pełne DTO ze źródła danych.
Wprawdzie to już rezygnacja z podstawowego elementu DDD, z drugiej jednak strony prosta, pragmatyczna, rozsądna architektura.

I tutaj wracamy do Bounded Context. Możemy mieć dwa konteksty: jeden do zapisu (encje) i drugi do odczytu (przeważnie DTO/VO).
Link do wypowiedziLink
Adrian C.

Adrian C.
projektant/programis
ta

Temat: [DDD]Fasada czy może warstwa aplikacji.

@Wojtek: oczywiście nie jest to tajne, ale przedstawianie całego diagramu UML encji biznesowych wydaje mi się zbędne, poza tym nie mam go przy sobie.
Przedstawie na predko kawalek uproszczony tego diagramu(BTW polecam: http://oryx-project.org/oryx/editor;uml2.2).
Diagram jest uproszczony na potrzeby przedstawienia problemu. Link do diagramu:diagram

Encje:
-User - reprezentuje użytkownika.
-Profile - reprezentuje nazwany(ID profilu) dokument ustawień dla użytkownika.
-Property - jedna właściwość ustawień, identyfikowana po nazwie.
VO:
-Address
-MailAddress
-UserID

W warstwie aplikacji mam serwis UserService, z metodą saveUserChanges.
Serwis wywoływany będzie przez akcję strutsowa, w samej warstwie UI, nie chcę używać encji User z wiadomych powodów. Dlatego UI będzie współpracowało z DTO, załóżmy że nazwę tą klasę UserDTO, która będzie miała property, które można edytować w encji User, czyli: firstName, lastName, secondName, plus oczywiście id usera itp.. Takie DTO przekażę jako parametr do metody saveUserChanges, no i w tej metodzie na podstawie DTO wyciągnę z repo encje User, zaktualizuję dane i zapiszę.
Taki mam pomysł, tylko wymaga to ode mnie tłumaczenia UserDTO->User, ale to chyba nie będzie duży problem.
Może macie jakieś inne pomysły?

@Alan: sugerujesz zrobienie kolejnej encji, która będzie reprezentowała User'a tylko na potrzeby zapisu danych?Adrian Chrzastowski edytował(a) ten post dnia 13.01.11 o godzinie 13:09
Link do wypowiedziLink
Dariusz Ludera

Dariusz Ludera Java, JEE and JVM
based languages
developer. System
archi...

Temat: [DDD]Fasada czy może warstwa aplikacji.

Alan Gabriel B.:

Możemy mieć dwa konteksty: jeden do zapisu (encje) i drugi do odczytu (przeważnie DTO/VO).

Jak dla mnie świetny pomysł, unikniemy translacji encja->DTO - do warstwy UI idzie wtedy odpowiednio spreparowany DTO. Po modyfikacjach tego DTO, zgodnie z tym co pisze Adrian, wyciągamy odpowiednią encję i utrwalamy zmiany pobrane z DTO (nie da się chyba uniknąć czegoś w rodzaju przepakowania DTO->encja). No chyba, że macie jeszcze bardziej 'pragmatyczny' pomysł?
Link do wypowiedziLink
Jacek Hełka

Jacek Hełka CCA Europe.pl Sp. z
o. o.

Temat: [DDD]Fasada czy może warstwa aplikacji.

Alan Gabriel B.:
Nic takiego nie proponowałem. Anemiczne modele to zło.
Twierdzę tylko, że - o ile soft na to pozwala (Hibernate pozwala) to - lepiej jest pominąć etap "przepakowywania" i pobierać od razu pełne DTO ze źródła danych.

Może źle się wyraziłem. Miałem na myśli bezpośrednie ciągnięcie DTO, bez pośrednictwa encji.

@Dariusz - bardzij pragmatycznie (a przynajmniej prościej) byłoby zapisywać bezpośrednio wykorzystując DTO bez pośrednictwa encji. Wprawdzie to niemal taka sama herezja jak nie używanie getterów i setterów, ale skoro grom z jasnego nieba we mnie nie uderzył, jak to napisałem...
Link do wypowiedziLink
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: [DDD]Fasada czy może warstwa aplikacji.

Adrian Chrzastowski:
@Wojtek: oczywiście nie jest to tajne, ale przedstawianie całego diagramu UML encji biznesowych wydaje mi się zbędne, poza tym nie mam go przy sobie.
Przedstawie na predko kawalek uproszczony tego diagramu(BTW polecam: http://oryx-project.org/oryx/editor;uml2.2).
Diagram jest uproszczony na potrzeby przedstawienia problemu. Link do diagramu:diagram

Encje:
-User - reprezentuje użytkownika.
-Profile - reprezentuje nazwany(ID profilu) dokument ustawień dla użytkownika.
-Property - jedna właściwość ustawień, identyfikowana po nazwie.
VO:
-Address
-MailAddress
-UserID

W warstwie aplikacji mam serwis UserService, z metodą saveUserChanges.
Serwis wywoływany będzie przez akcję strutsowa, w samej warstwie UI, nie chcę używać encji User z wiadomych powodów. Dlatego UI będzie współpracowało z DTO, załóżmy że nazwę tą klasę UserDTO, która będzie miała property, które można edytować w encji User, czyli: firstName, lastName, secondName, plus oczywiście id usera itp.. Takie DTO przekażę jako parametr do metody saveUserChanges, no i w tej metodzie na podstawie DTO wyciągnę z repo encje User, zaktualizuję dane i zapiszę.
Taki mam pomysł, tylko wymaga to ode mnie tłumaczenia UserDTO->User, ale to chyba nie będzie duży problem.
Może macie jakieś inne pomysły?

@Alan: sugerujesz zrobienie kolejnej encji, która będzie reprezentowała User'a tylko na potrzeby zapisu danych?

Widzę, że piszesz to w Javie. Jeżeli mogę dodać swoje trzy grosze to:
-UserService to raczej nie serwis w znaczeniu DDD a wg. mnie fasada
-Znam ideę DTO, natomiast w tej aplikacji, jeżeli chodzi o transfer danych między widokiem a biznesową resztą to pokusiłbym się o zastosowanie jakiegoś prostego rozwiązania np. zwykłej tabeli asocjacyjnej - dzięki temu nie wprowadzamy dodatkowych zależności a weryfikacja danych i tak nastąpi czy to w fasadzie czy przy ustawianiu stanu odpowiedniego obiektu encji ( w tym przypadku Usera )

Btw. trochę linków o DDD m.in z samplowymi aplikacjami znajdziesz na moim blogu -> http://blog.wsoczynski.pl/2010/08/10/domain-driven-des...Wojciech Soczyński edytował(a) ten post dnia 13.01.11 o godzinie 14:16
Link do wypowiedziLink
Adrian C.

Adrian C.
projektant/programis
ta

Temat: [DDD]Fasada czy może warstwa aplikacji.

Wojtek, nazwa mojego serwisu jest może myląca, ale tj. pisałem jest to serwis w warstwie aplikacji, na jego metody nałożona jest transakcyjność i bezpieczeństwo. Wszystkie metody tego serwisu współpracują z encjami, serwisami, repozytoriami i fabrykami z warstwy domenowej i na nich wywołują metody biznesowe. Warstwę aplikacji, chciałbym przykryć fasadą pod konkretny widok, w tym przypadku strutsa.
Tablica o której pisałeś jest jakimś rozwiązaniem, tylko to taka prostsza wersja DTO.
Widziałem już wcześniej tego bloga :) ale nie skojarzyłem autora z Tobą.
Link do wypowiedziLink
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: [DDD]Fasada czy może warstwa aplikacji.

Adrian Chrzastowski:
Wojtek, nazwa mojego serwisu jest może myląca, ale tj. pisałem jest to serwis w warstwie aplikacji, na jego metody nałożona jest transakcyjność i bezpieczeństwo. Wszystkie metody tego serwisu współpracują z encjami, serwisami, repozytoriami i fabrykami z warstwy domenowej i na nich wywołują metody biznesowe. Warstwę aplikacji, chciałbym przykryć fasadą pod konkretny widok, w tym przypadku strutsa.
Tablica o której pisałeś jest jakimś rozwiązaniem, tylko to taka prostsza wersja DTO.
Widziałem już wcześniej tego bloga :) ale nie skojarzyłem autora z Tobą.

Koniec końców wydaje mi się, że ta dodatkowa fasada między częścią biznesową a strutsami jest dobrym pomysłem :>. Jak już skończysz swój app, to jeżeli jest to projekt edukacyjno-samplowy to fajnie by go było wrzucić na githuba, myślę, że był by to dobry materiał dla każdego kto stawia swoje pierwsze kroki w DDD.
Link do wypowiedziLink
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: [DDD]Fasada czy może warstwa aplikacji.

Dariusz Ludera:
Jak dla mnie świetny pomysł, unikniemy translacji encja->DTO - do warstwy UI idzie wtedy odpowiednio spreparowany DTO. Po modyfikacjach tego DTO, zgodnie z tym co pisze Adrian, wyciągamy odpowiednią encję i utrwalamy zmiany pobrane z DTO (nie da się chyba uniknąć czegoś w rodzaju przepakowania DTO->encja). No chyba, że macie jeszcze bardziej 'pragmatyczny' pomysł?

To zależy... w pasywnym MVC (www) da się uniknąć przepakowywania, bo odczyt i zapis są rozróżnialne na poziomie HTTP. W aktywnym (desktopy) zostawiłbym encje tak jak są bez dodatkowych DTO, ewentualnie przy bardziej skomplikowanej dziedzinie pakowałbym w DTO rożnego rodzaju statystyki lub okrojone wersje encji (w celu wyświetlenia bez możliwości zapisu).
Link do wypowiedziLink
Dariusz Ludera

Dariusz Ludera Java, JEE and JVM
based languages
developer. System
archi...

Temat: [DDD]Fasada czy może warstwa aplikacji.

Jacek Hełka:

bardzij pragmatycznie (a przynajmniej prościej) byłoby zapisywać bezpośrednio wykorzystując DTO bez pośrednictwa encji. Wprawdzie to niemal taka sama herezja jak nie używanie getterów i setterów, ale skoro grom z jasnego nieba we mnie nie uderzył, jak to napisałem...

Mogę się mylić, ale wydaje mi się, że jest to 'wybicie pierwszego okna' jeszcze przed procesem implementacji, jeżeli już w fazie projektowania decydujesz się na jazdę bez trzymanki, to w czasie implementacji (i później podczas utrzymania projektu) może być chyba tylko gorzej.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Przykład DDD




Wyślij zaproszenie do
Anuluj