CQRS, Clean architecture - autoryzacja i kontrola dostępu

Cześć, piszę sobie prosty komunikator wykorzystując CQRS oraz Clean architecture i zastanawiam się w jaki sposób najlepiej zaimplementować kontrolę dostępu do danego zasobu.

Obecnie robię to w ten sposób, że na poziomie Spring'owych kontrolerów wyciągam zalogowanego użytkownika oraz przekazuję jego id/username do komendy lub zapytania. W tym rozwiązaniu każdy zasób wymagający kontroli dostępu wymaga przekazania do komendy/zapytania id/username użytkownika, który wykonuje daną operację. Czy to rozwiązanie jest poprawne i jakie mam alternatywy?

Przykład:

class ConversationCreateCommand {
    private String creatingUser;
    ...
}

class MessageSearchQuery {
    private String searchingUser;
    ...
}

w javie nikt nie używa cqrsa :/

WeiXiao napisał(a):

w javie nikt nie używa cqrsa :/

Rozumiem że byłeś wszędzie i wszystko widziałeś? W takim razie na pewno wiesz co powiedział Odyn Baldurowi przed spaleniem :P

Nie możesz użyć @PreAuthorize itp na warstwie serwisów, przed wejściem w warstwę domenową (tak żeby obiekty domenowe i agregaty nie były skażone Spring Security)?

Charles_Ray napisał(a):

Nie możesz użyć @PreAuthorize itp na warstwie serwisów, przed wejściem w warstwę domenową (tak żeby obiekty domenowe i agregaty nie były skażone Spring Security)?

Moja warstwa serwisów - command/query (przypadki użycia) i handlery jako serwisy są poniekąd częścią domeny i raczej nie powinny zawierać spring'owych adnotacji.
Robię tak jak mówisz tylko na najniższej warstwie czyli w moim przypadku warstwie ui (kontrolery).

Napisałem „przed wejściem do domeny”. Poczytaj o serwisach aplikacyjnych: https://enterprisecraftsmanship.com/posts/domain-vs-application-services/

Charles_Ray napisał(a):

Napisałem „przed wejściem do domeny”. Poczytaj o serwisach aplikacyjnych: https://enterprisecraftsmanship.com/posts/domain-vs-application-services/

Tak, znam pojęcie serwisów aplikacyjnych z DDD, których zadaniem jest zarządzanie obiektami domeny jednak nie powinny zawierać logiki biznesowej. U mnie własnie takimi serwisami aplikacyjnych są handlery, nie widzę jednak powodu żeby uzależniać je od całego frameworka z powodu adnotacji.

A co jest złego w przekazaniu usera do Commanda/Query, skoro i tak pewnie sprawdzasz uprawnienia w domenie?

danek napisał(a):

A co jest złego w przekazaniu usera do Commanda/Query, skoro i tak pewnie sprawdzasz uprawnienia w domenie?

Wydaje mi się, że nic złego, głównie zastanawia mnie skalowalność tego rozwiązania i czy istnieje lepsza alternatywa o której nie pomyślałem.

Jeśli sprawdzasz uprawnienia potem w domenie, to i tak jakoś informację o użytkowniku musisz tam przekazać