DDD: Co wchodzi w domenę i co znajduje się w aplikacji?

Question

Trudno mi jest zdecydować, czy coś powinno być częścią domeny czy aplikacji.

Czytanie tego answer bardzo pomaga przy pojęciach takich, jak autoryzacja, ale wciąż mam problemy z innymi rzeczami.

Aby zilustrować moje zamieszanie, rozważ zgłoszenie komentarza. Oto rzeczy, które muszą się wydarzyć, zanim komentarz zostanie opublikowany. W nawiasie wskazuję, gdzie według mnie powinna funkcjonować ta funkcja.

• Upewnij się rola użytkownika/status może wypowiedzieć się na temat tego postu (autoryzacja, idzie do aplikacji)
• Upewnij słupek, do którego jesteśmy komentując istnieje i jest publikowana (domena)
• Upewnij użytkownikowi nie opublikował więcej niż 5 komentarzy w ostatniej chwili (dławienie, intuicja mówi, że chodzi o Aplikację)
• Upewnij się, że komentarz nie jest pustym ciągiem (Domena)
• Upewnij się, że komentarz nie zawiera brudnych słów (Domena?)
• Upewnij komentarz nie ma duplikatów z samego użytkownika w tym poście (domena?)
• Format komentarz (aplikacji)
• usunięcia niektórych tagów HTML z komentarzem, które nie są dozwolone dla bieżącego użytkownika (aplikacji)
• Sprawdź komentarz do spamu (Aplikacja?)

Nie mogę zdecydować, czy sprawdzanie komentarza dla spamu dotyczy domeny czy aplikacji, to samo dotyczy dławienia. Z mojego punktu widzenia obie te kwestie są dla mnie ważne i muszą być obecne. Ale to samo dotyczy autoryzacji i wiemy, że nie powinno być w domenie.

Jeśli podzielę te obawy między usługą domenową i usługą aplikacji, mam wrażenie, że moja domena nie jest w pełni egzekwowana i w rzeczywistości polega na aplikacji do wstępnych kontroli. W takim razie, o co w tym wszystkim chodzi, dlaczego po prostu nie zrobię tego wszystkiego w aplikacji, aby zmniejszyć zamieszanie?

Moja obecna konfiguracja to robi:

Controller -> App.CommentingService.Comment() -> Domain.CommentingService.Comment()

Byłoby pomocne, jeśli ktoś może przejść przez wszystkie wymagane kroki, aby utworzyć komentarz i przypisać go do właściwej warstwy daje pewne uzasadnienie.

Answer 1

Twoja konfiguracja wygląda prawidłowo. Usługi aplikacji często występują w 2 wersjach:

Funkcje aplikacji: powiadomienia e-mail, autoryzacja, trwałość itd. Wszystkie funkcje, poza domeną, Twój system pojawiły się tutaj.

Koordynacja aplikacji: Aby spełnić przypadek użycia, należy skoordynować funkcje aplikacji i domenę. Cała hydraulika przychodzi tutaj.

Należy pamiętać, że modele koordynacji aplikacji używają przypadków, więc nie zawsze są zgodne z usługą 1 aplikacji = 1 usługa domeny, ponieważ przypadek użycia może obejmować więcej niż jeden proces.

Controller 
    App.CommentingService.Comment() //coordination of below features and domain 
     App.AuthService().Autorize(); //feature 
     Domain.CommentingService.Comment(); //domain 
     App.PersistenceService().Persist(); //feature 
     App.NotificationService().SentNotificationToUser(); //feature 

Dlaczego nie mogę po prostu zrobić to w aplikacji, aby zmniejszyć zamieszanie?

Podział odpowiedzialności, luźne powiązanie, brak zależności, itp .; wszystko to jest dobre z wielu powodów. Dam ci prawdziwy przykład, w którym byłem ostatnio zaangażowany: posiadanie luźnego zestawu par (w środowisku .NET) z usługami tylko Domain pozwala mi hostować tę samą domenę nietkniętą w aplikacji sieciowej, DesktopApp i usłudze sieciowej SOAP właśnie zmiana usług koordynacji aplikacji, ponieważ wymagania i przypadki użycia są różne w każdej aplikacji.

Informacje o tym, co wchodzi w domenę, a co nie. Bardzo trudno jest dać bezpośrednią odpowiedź, ponieważ zależy to od tego, jaka jest twoja domena.

tj

Upewnij użytkownik nie opublikował więcej niż 5 komentarzy w ostatniej chwili

Masz na pytanie dlaczego dławienie? Aby zapobiec niechlujnemu interfejsowi użytkownika? Przyczyna wydajności? Zapobiegać zagrożeniu Denial of Service? Albo łamie regułę w twojej "grze", ponieważ twoja "gra" daje tylko ograniczone próby dla użytkownika w spamie czasu? To właśnie wskazuje, kiedy coś jest domeną lub aplikacją.