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?
Mógłbyś bardziej opisać swój problem?
Jeśli nie wiesz co to Try...Catch to proszę:
https://docs.microsoft.com/pl-pl/dotnet/csharp/language-reference/keywords/try-catch
No ale mi chodzi o jakieś eleganckie rozwiązanie.
Czyli?
@Mondonno: Znasz się na DDD? Bo długo by tłumaczyć ;)
Mam podpięty filtr w ASP.necie który tłumaczy wyjątek na odpowiednią odpowiedź http.
@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.
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.
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.
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.
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.
@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.
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.
@somekind: Zdarzyło Ci się kiedyś mieć RDM? Co to była za aplikacja?
Ale pytasz, czy faktycznie był RDM, czy architekt twierdził, że jest RDM?
Taki prawdziwy ;)
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.
Co to jest ADM?
Co to znaczy "robienie tego w DDD"?
@somekind
Może zostałeś wezwany na dywanik, bo czegoś nie zrozumiałeś.
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ę"
Oho, wrócił ten ewangelista DDD. Jak mu tam było? Jakoś na G.
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.
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?
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.