Przechwytywanie wyjątków z warstwy domeny

0

W jaki sposób przechwytujecie wyjątki lecące z warstwy domeny w warstwie aplikacji? Robicie coś w stylu var operationResult = Try(() => aggregateRoot.DoSth()), gdzie Try jest jakimś helperem mapującym wyjątki z domeny na obiekty rezultatu?

0

Mógłbyś bardziej opisać swój problem? 😕

0

No ale mi chodzi o jakieś eleganckie rozwiązanie.

0

Czyli?

0

@Mondonno: Znasz się na DDD? Bo długo by tłumaczyć ;)

3

Mam podpięty filtr w ASP.necie który tłumaczy wyjątek na odpowiednią odpowiedź http.

0

@mad_penguin: Ok, a zwracasz jakiś Result z warstwy aplikacji, czy stwierdziłeś, że nie pasuje to do DDD i po prostu używasz wyjątków? Bo takie podejście głównie widzę w przykładowych repo.

1

Ja podszedłem w ten sposób, że z domeny zwracam Either, który zawiera albo event utworzony na podstawie wywołanej akcji, albo OperationError, który zawiera informacje co spowodowało błąd w operacji. Może to być nawet głupio spisany message per przypadek, który po prostu bedzie logowany i wypychany wyżej, jeśli potrzeba.

0

@Klojtex: Próbuję zrobić coś takiego u siebie, ale widzę, że takie podejście jest zdecydowanie mniej popularne, patrząc po repozytoriach na GitHubie. Wołam @somekind, @Aventus, @neves ;)

1

No jak już używasz wyjątków w domenie, to po co je łapać i przepakowywać w warstwie aplikacji? Jaką wartość ma to nam wnieść bo nie dostrzegam tego? Dlatego ja głosuje za filtrami/exception handlererami.

0

Czyli że robić coś takiego? encja serwis Tj. nie zwracać żadnego Result?

1

Ja tak samo jak Neves- używasz globalnego łapania wyjątków i robisz z nimi co trzeba. To może zależeć od konkretnego wyjątku jeśli istnieje taka potrzeba.

1

Nie używam DDD. Problem solved. :P

Ale nawet w CRUDzie albo w normalnych projektach zwracał bym wynik zamiast rzucać wyjątki.
Globalna obsługa errorów poprzez filtr/handler, to jeszcze inna para kaloszy, i jak dla mnie obowiązkowa, niezależnie od tego, do czego projekt służy i jakich wzorców używa.

0

@somekind: Hmm, pisałeś ostatnio, że rozwijasz dwuletni projekt, w którym nie ma co szukać bugów. Wątpię, że masz anemiczny model. Jednocześnie piszesz, że nie używasz DDD. Wiem, że są to ortogonalne pojęcia, ale jednak ciekaw jestem, jak ten model u Ciebie wygląda w projekcie.

1

Jeśli chodzi o ten projekt, to nie powiedziałbym, że tam w ogóle jest jakiś model dziedziny. Ten projekt to integracja, czyli odbiera dane z jednych serwisów, czasami połączy kilka źródeł w jedno, a czasami tylko zmapuje 1:1, i odsyła do jakichś zewnętrznych konsumentów. Jedyna logika jaka tam jest, to albo autoryzacyjna, albo "nie wywołuj drugiego serwisu, jeśli pierwszy niczego nie zwrócił". Robienie tego w DDD byłoby mocnym overkillem. Tam jest dużo DTO, bardzo dużo DTO, a jakieś serwisy operują na nich bezpośrednio, więc jeśli na siłę chcieć to jakoś otagować, to jest to raczej ADM niż cokolwiek innego.

0

@somekind: Zdarzyło Ci się kiedyś mieć RDM? Co to była za aplikacja?

0

Ale pytasz, czy faktycznie był RDM, czy architekt twierdził, że jest RDM?

0

Taki prawdziwy ;)

0

No to tak chyba raz - był sobie strasznie skopany projekt (WebFormsy w najgorszej możliwej opcji, z SqlDataSource, czyli w jednym pliku wymieszany HTML i SQL, zero testowalności) przerabiałem w wolnym czasie z kolegami na DDD. Tylko tam były 3 encje i 2 agregate rooty. No i nie było przez nikogo używane.

A jak kiedyś zacząłem pisać DDD w projekcie, który był reklamowany jako DDD, ale tak naprawdę miał ADM (chociaż niektórzy twierdzą, że to się wcale nie kłóci, bo DDD masz wtedy, gdy "dbasz o projekt" :D), to potem zostałem wezwany na dywanik za psucie morale w zespole.

0

Co to jest ADM?
Co to znaczy "robienie tego w DDD"?

@somekind
Może zostałeś wezwany na dywanik, bo czegoś nie zrozumiałeś.

0

DDD - Domain Driven Design; ADM - Anemic Domain Model, czyli DTO furgające po serwisach i radosna proceduralność

ADM w kontekście DDD to nie jest, DTO furgające po serwisach i radosna proceduralność.

A wezwany na dywanik został raczej dlatego, że to koledzy nie rozumieli czym jest DDD i programowanie obiektowe. Przynajmniej tak bym podejrzewał po opisie :)

To brzmi jak dobry dowcip :P

Może inaczej co jest przyczyną ADM, podpowiem, że jedną z nich DDD opisuje jako "amnezję"

3

Oho, wrócił ten ewangelista DDD. Jak mu tam było? Jakoś na G.

3
Emasło napisał(a):

@somekind
Może zostałeś wezwany na dywanik, bo czegoś nie zrozumiałeś.

No ja wielu rzeczy nie rozumiałem w tym projekcie, np. po co jest 11 warstw, z których większość służy do przemapowania i przepchania DTO niżej, a faktyczna logika jest głównie w triggerach. Albo czemu build trwa godzinę. Albo czemu zmiana CSSa wymaga buildu. Albo czemu build jest i tak szybszy niż start aplikacji.
Nie zrozumiałem pewnie dlatego, że byłem w tym projekcie tylko 2 sprinty, czyli pół roku.

No, ale abstrahując od tych szczegółów, to tam pewnie gdzieś było strategiczne DDDD (pierwsze D od Debest) zgodne z zieloną książeczką (albo żółtymi papierami). Nie wiem. Chyba mam po prostu zbyt słaby wzrok, żeby je dojrzeć w całej masie kupy, która obrastała to przedsięwzięcie.

0

po co jest 11 warstw, z których większość służy do przemapowania

hehe, bo to jest SRP no i projekt musi być otagowany automapperem. :D

W żółte papiery to nie wnikam, ale jak byś naprawił ten projekt?

0

Tam nie było automappera. SRP też nie.

Nie było też jak tego naprawić, można jedynie zrobić od nowa. Pięciu juniorów w dowolnej technologii by to zrobiło w pół roku.

1 użytkowników online, w tym zalogowanych: 0, gości: 1