DDD i sterowanie przepływem przez wyjątki

Odpowiedz Nowy wątek
2019-03-11 18:25
0

Znalazłem ostatnio aplikację napisaną zgodnie z DDD (o której pozytywnie się wypowiadaliście) i zobaczyłem, że metody w encjach dokonują walidacji argumentów, a informacje o błędach przekazują poprzez wyjątki, tak jak np. tu albo tu. No ale przecież sterowanie przepływem przez wyjątki jest złe, więc pewnie w warstwie aplikacji wykonywana jest osobna walidacja. Tylko że to oznacza duplikację kodu. Czy czegoś nie rozumiem?

Pokaż pozostałe 2 komentarze
@nobody01: usunąłem mój post, bo coś mi się przewidziało, że tam jest List, ale z IEnumerable nie ma problemu, który opisałem. - Burmistrz 2019-03-11 19:11
Jeśli chodzi o dobre praktyki, to autor tak naprawdę może wiedzieć, że według większości programistów to co robi nie jest z nimi zgodne, ale może go to nie obchodzić, bo tak mu pasuje. Znam trochę programistów, którzy mają własne poglądy na temat pewnych spraw i nie dadzą się przekonać, że nie powinno się tak robić. - Burmistrz 2019-03-11 19:21
Nigdy nie znajdziesz projektu idealnego. - Kokoniłaj 2019-03-11 19:57
I to jest najgorsze: nie ważne, ile czasu poświęcę, i tak nie napiszę naprawdę dobrego kodu. ;( - nobody01 2019-03-11 20:00

Pozostało 580 znaków

2019-03-11 19:05
1

Te switche tylko po to by zwrócić wyjątek wyglądają strasznie :D.

Wprawdzie obecnego kursu Piotra nie widziałem jeszcze, o tyle obejrzałem cały poprzedni, "Becoming a software developer". I o ile się to dobrze ogląda i słucha, i jest to w miarę przekrojowe pokazanie różnych technologi. O tyle finalny kod który powstał przez cały kurs, to wielka nie działająca kupa i zlepek różnorodnych pomysłów, który pokazuje jak można przeinżynierować prostego CRUDA i go nie dowieźć do końca ;). Także do kodu bym podchodził z dystansem, bo główna wiedza jest przekazywana w trakcie odcinka, a kod jest traktowany jako obywatel drugiej kategorii.

Co do walidacji czy też sprawdzania niezmienników, jeśli chcemy mieć zawsze poprawny model domenowy, to to jest to niesamowity ból, bez względu którą droga pójdziemy.
Używanie Exceptionów wprawdzie złe i wolne, wymaga jednak mniej pracy niż zwracanie Result.


Java to taki C# tyle że z gorszą składnią.
edytowany 2x, ostatnio: neves, 2019-03-11 19:12

Pozostało 580 znaków

2019-03-11 19:13
0

W "Domenie" wyjątki powinny utrzymywać ograniczenia "niezmienniki" Gościu zrobił sobie jakąś walidacje punktu wejścia pod klienta na swichu. Poza tym większość Asercji dla constrain można się pozbyć. Pisałem już, że te przykłady to wprowadzenie do infrastruktury związanej z deploymentem - mikroserwisami, a nie wyznacznik jakości kodu. Poza tym, kto powiedział, że ten projekt ma coś wspólnego z DDD ?


Unhandled Exception: System.MissingMethodException: Constructor on type 'System.Exception' not found.

Pozostało 580 znaków

2019-03-11 19:18
0

To jakby wyglądała poprawna wersja encji Order? Tzn. może nie tyle poprawna w sensie DDD, co po prostu pragmatyczna.

edytowany 1x, ostatnio: nobody01, 2019-03-11 19:19

Pozostało 580 znaków

2019-03-11 19:27
1

Tu masz porównanie różnych podejść:
https://enterprisecraftsmansh[...]016/09/13/validation-and-ddd/

w zależności od kontekstu któreś z nich może być lepsze od innego, ale prawda jest taka że każde z nich to wybór mniejszego zła, bo walidacja/niezmienniki to ciężki temat który nie doczekał się dobrego rozwiązania, temat który jest często pomijany w opracowaniach.


Java to taki C# tyle że z gorszą składnią.
edytowany 1x, ostatnio: neves, 2019-03-11 19:29
Jak dla mnie to słaby ten artykuł :P - Gworys 2019-03-11 19:38
byłbym bardzo wdzięczny gdybyś mi dostarczył lepszy, traktujący o tej tematyce ;) - neves 2019-03-11 19:41
Może kiedyś sam go napiszę :P - Gworys 2019-03-11 19:53

Pozostało 580 znaków

2019-03-11 19:35
1
    9         public void Complete()
    8         {
    7             AssertThatCanComplete();
    6 
    5             Status = OrderStatus.Completed;
    4         }
    3 
    2         private void AssertThatCanComplete()
    1         {
 69              if (Status != OrderStatus.Available)
    1             {
    2                 throw new InvalidOperationException("Can not complete order.");                                                        
    3             }                                                                                                                          
    4         } 

plus Walidacja po stronie aplikacji


Unhandled Exception: System.MissingMethodException: Constructor on type 'System.Exception' not found.

Pozostało 580 znaków

2019-03-11 19:37
0

@neves:

Dlaczego to niby nie są dobre rozwiązania?

Dodatkowo można byłoby wykorzystać ValueTuple aby usprawnić te mechanizmy.

edytowany 3x, ostatnio: WeiXiao, 2019-03-11 19:37
Pokaż pozostałe 3 komentarze
Tuple to do rzeczy związanych z infrastrukturą. Do tego Either byłby dobry, ale tylko wtedy kiedy sytuacja nie jest "wyjątkowa" to znaczy wynik procesu może zwrócić zawsze dwa wyniki a ten wynik nie jest spowodowany błędem aplikacji. - Gworys 2019-03-11 19:45
@neves: No tak, bo przecież nie można dobrze nazwać metody oraz argumentów VT. Nie widzę żadnej zalety z użycia klasy nad VT do takich rzeczy jak walidacja. - WeiXiao 2019-03-11 19:45
Ja prefereuje CleanMonads. - Gworys 2019-03-11 19:47
@Gworys: hmm? (bool ActionPerformedProperly, Error Error, Output Output) albo ewentualnie Output? w c#8 - WeiXiao 2019-03-11 19:47
O... nie odpisałem ci. Ja preferuje monady Maybe albo Either. W ''Output?'' z C# 8, jeśli pamiętam tylko IDE sprawdza, czy masz ifa na nulla. A do samej walidacji "encji domenowej" staram się robić specyfikacje w ciekawszych sytuacjach niż walidacja emaila. - Gworys 2019-03-11 22:44

Pozostało 580 znaków

2019-03-11 19:48
0

Czyli wychodzi na to, że najlepiej tak:

  • prostą walidację (np. null-check, length-check) robimy przy użyciu fluent validation
  • walidację "biznesową" robimy za pomocą dodatkowej metody walidacyjnej w encji, którą wywołujemy w warstwie aplikacji przed wykonaniem operacji (dla bezpieczeństwa wrzucamy ją też do właściwej metody wykonującej operację)

Ten transaction script dużo prostszy. :P

2. To zależy - Gworys 2019-03-11 19:50

Pozostało 580 znaków

2019-03-12 00:13
3
nobody01 napisał(a):

No ale przecież sterowanie przepływem przez wyjątki jest złe, więc pewnie w warstwie aplikacji wykonywana jest osobna walidacja. Tylko że to oznacza duplikację kodu. Czy czegoś nie rozumiem?

Ale tu przecież nie ma żadnego sterowania przepływem, a co dopiero przez wyjątki. Konstruktor klasy robi to, co do niego należy - czyli tworzy spójny i użyteczny obiekt, albo nie tworzy go wcale rzucając przy okazji wyjątek.
Czy to duplikacja walidacji z warstwy aplikacji? Nie powiedziałbym, to raczej dodatkowe zabezpieczenie. Co jeśli ktoś nie napisze walidatora? Co jeśli walidator nie zostanie uruchomiony? Co jeśli pojawi się nowe źródło encji niezwiązane z dotychczasową warstwą aplikacji? Potem powstaną jakieś niedorobione encje, i prędzej czy później w bazie pojawią się zepsute dane, albo skądś poleci NRE. I kilka minut oszczędności w pisaniu porządnego kodu zamieni się w wiele godzin debugowania spaghetti.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-03-12 00:23
0

@somekind:

Z jednej strony tak, każda funkcja powinna mieć własną walidację, a szczególnie jeżeli pracujesz w NASA :) ale z drugiej zaczyna to dziwnie wyglądać jeżeli 80% kodu to sprawdzanie danych w niedużych appkach.

Jeżeli ktoś dobrze tego nie ogarnie pod względem wydzielenia, to będzie to koszmarne w użytkowaniu :P

edytowany 2x, ostatnio: WeiXiao, 2019-03-12 00:25

Pozostało 580 znaków

2019-03-12 00:26
0

Nieprawda, że każda funkcja - tylko te publiczne w publicznych klasach. I konstruktory obiektów. Nie zauważyłem, żeby stanowiło to 80% kodu, nie sądzę, aby stanowiło nawet 10%. Za to można oszczędzić w ten sposób na dziwnych błędach i wyjątkach na produkcji.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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