Notyfikacje w architekturze heksagonalnej

Bawię się znowu w architekture heksagonalną i piszę coś w rodzaju forum / bloga / aplikacji społecznościowej. No i mam sobie przykładową domenę Post, która jest odpowiedzialna za wszelkie CRUDowe operacje na postach. Dodatkowo, chcę powiadomić użytkowników gdy coś się stanie, np. :

• obserwowana osoba dodała nowego posta
• ktoś polubił mojego posta
• ktoś dodał komentarz do mojego posta

Wygląda mi to, na potrzebę stworzenia kolejnej domeny odpowiedzialnej za handling takich eventów, tzn. określenie faktycznej grupy odbiorców danego eventu oraz wypchnięcie do nich notyfikacji przez WebSocket i ewentualne zapisanie tego w bazie danych, jeżeli w danej chwili odbiorcy nie są online.

No i z punktu widzenia architektury heksagonalnej: (package per feature, package scoped)

1. Czy taki serwis odpowiedzialny za notyfikację użytkowników do faktycznie kolejna domena czy część infrastruktury?
2. Jak się komunikować z takim serwisem?

• Jeżeli to domena to po prostu dorzucać NotificationFacade to każdej innej domeny która może produkować różne eventy i wołać to synchronicznie?
• Czy może Springowy ApplicationEventPublisher będzie tutaj idealnym rozwiązaniem? To mimo wszystko dość mały projekt, tak więc zdecydowałem że encje domenowe == encje biznesowe, tak więc i tak trochę Springa będzie wewnątrz domeny.

Notyfikacja to abstrakcja(port) a sposób wysłania notyfikacji to implementacja(adapter wychodzący)

Domena domeną ale nie zapominaj, że to przede wszystkim ma się skalować. Jeśli takie event'y np będą przychodzić kolejką czy jakąś tam kafka-streams / spark lub nawet REST'em, to
NotificationFacade w każdej domenie, będzie wymagał również w każdej domenie IN'a i OUT'a do notyfikacji, wyobraź sobie, że chcesz każdy taki serwis osobno deployować, teraz każdy z nich musi pushować websocketem i konsumować komunikaty - to od groma roboty nie wspominając o synchronizacji i utrzymywaniu tego później.

Czy każda notyfikacja odbywa się tak samo? Może jakiś rodzaj notyfikacji, korzysta dodatkowo z różnych IO - powiadomienie pocztą / sms'em / wiadomość prywatna na forum - wtedy też na problem należy spojrzeć od strony skalowalności bo to będą czesto zew usługi które też mają jakieś tam swoje ograniczenia.

Nie pchaj Springa w domene, możesz skorzystać z ApplicationEventPublisher nie mając w domenie Springa, przecież o to właśnie chodzi w clean architecture / hexa.

Ja bym zaczął od wersji najprostszej a w miarę rozbudowywania projektu poznasz lepiej problem i wtedy będzie łatwiej podjąć decyzje dotyczącą podziału.

A komunikować to się można tak:

notificationFacade.sendNotification(...); taka fasada mogłaby być dołączona jako jar do każdego modułu który wysyła jakieś notyfikacje. Byłby to zwykły klient jakiejś kolejki / kafki / sparka / rest / soap, inny modul konsumuje komunikaty pushujac na websocket - tak bym to widzial raczej.

Wiec wedlug mnie to tak - notyfikacje sa osobna domena, inne moduly korzystaja z modulu do notyfikacji ktory ma public scope'y dla fasady, Notification (jakis tam dto, ktory przyjmuja metody fasady za argument z ladnymi metodami statycznymi do tworzenia obiektow :P)

Generalnie myslenie o architekturze w ten sposob ma sens tylko wtedy, jesli aplikacja nie jest CRUD'em. Bo jak pewnie wiesz, te rozne podejscia sprowadzaja sie glownie do tego, zeby logike aplikacji miec niezalezna od infrastruktury. Jesli aplikacja jest CRUD'em to tam nie ma logiki wiec nie bardzo jest nad czym sie gimnastykowac. Sprobuj zaprogramowac cos, co bedzie ja mialo - cos we wlasnym obszarze zainteresowan, u mnie swego czasu to byly programy do ukladania diet (i logika bylo ukladanie posilkow i liczenie kcal) a teraz sa to strategie gieldowe (logika to zajmowanie / zamykanie pozycji w zaleznosci od wartosci wskaznikow).

Btw zapomniales o najwazniejszym - TDD - zacznij od testu jak Jakub to Ci sie wszystko samo pouklada zobaczysz :P

AngryProgrammer napisał(a):

1. Czy taki serwis odpowiedzialny za notyfikację użytkowników do faktycznie kolejna domena czy część infrastruktury?

W twoim kontekście część infrastruktury. Gdybyś miał bazylion reguł biznesowych dla tych eventów i niezwiązanych z samym blogiem to możnaby się zastanawiać nad osobną domeną. Jak na razie to każdy podział domeny spowoduje niepotrzebne obniżenie cohesion.

AngryProgrammer napisał(a):

1. Jak się komunikować z takim serwisem?

Jeżeli wszystkie powiadomienia są podobnego rodzaju to za pomocą np. interfejsu BlogEventNotifier w domenie bloga i implementacji WebsocketBlogEventNotifier, która ogarnia websocket i persystencję w infrastrukturze bloga.

AngryProgrammer napisał(a):

zdecydowałem że encje domenowe == encje biznesowe, tak więc i tak trochę Springa będzie wewnątrz domeny.

No więc nie masz architektury heksagonalnej. Szczególnie jeżeli mówimy o cieknących frameworkach jak Hibernate. Twój design jest sterowany potrzebami frameworka a nie przykładowo poprawnością domeny (przykładowo mutowalne encje vs value objects)

Co do dzielenia tego na osobne jary czy rozwiązywania potencjalnych problemów ze skalowalnością, nie chciałbym iść tą drogą. Koniec końców to projekt hobbystyczny, w którym chcę się skupić na samej architekturze.

Co do samego podziału odpowiedzialności, nie bardzo wiem jak to rozwiązać.
Weźmy taki przykład, w którym nie muszę korzystać z Springowych eventów

class PostCreator {
    private final PostRepository postRepository;
    private final NotificationFacade notificationFacade;

    PostCreator(PostRepository postRepository, NotificationFacade notificationFacade) {
        this.postRepository = postRepository;
        this.notificationFacade = notificationFacade;
    }

    PostDto createPost(CreatePostCommand command) {
        final var savedPost = postRepository.save(toEntity(command));
        final var postDto = savedPost.toDto();
        this.notificationFacade.publishNotification(new PostCreatedNotification());
        return postDto;
    }
}

public class PostCreatedNotification implements Notification {
    @Override
    public Channel getChannel() {
        return Channel.WEB_SOCKET;
    }
}

No i NotificationFacade po prostu deleguje takie wywołanie do

class NotificationPublisher {

    private final WebSocketPublisher webSocketPublisher;
    private final EmailPublisher emailPublisher;

    public NotificationPublisher(WebSocketPublisher webSocketPublisher, EmailPublisher emailPublisher) {
        this.webSocketPublisher = webSocketPublisher;
        this.emailPublisher = emailPublisher;
    }

    public void publishEvent(Notification notification) {
        CompletableFuture.runAsync(() -> this.processAndPublish(notification));
    }

    private void processAndPublish(Notification notification) {
        //do some processing?
        switch (notification.getChannel()) {
            case WEB_SOCKET -> webSocketPublisher.publish(notification);
            case EMAIL -> emailPublisher.publish(notification);
        }
    }
}

Gdzie WebSocketPublisher oraz EmailPublisher to interfejsy, zaimplementowane gdzieś w infrastrukturze. No i na tym przykładzie, musze zdecydować do kogo trafi to powiadomienie, czyli powiedzmy muszę iść do domeny User, znaleźć użytkownika który stworzył posta i jako odbiorców ustawić coś w stylu user.getFollowers(). Gdzie to zrobić? Dodam, że tych reguł może być więcej. Sam PostCreator powinien odpowiadać również za stworzenie kompletnej notifykacji, czyli powinien iść po dane użytkownika itp? Wtedy po stronie serwisu odpowiedzialnego za notyfikację, zostaje część techniczna, czyli np. skierowanie tego na odpowiedni topic. Pytanie czy nadal ma sens robienie z tego domeny i pisanie tych interfejsów, jak wszystko co się wewnątrz tego dzieje jest związane z frameworkiem, czy takie notyfikacje to już nie jest stricte część infrastruktury.

Więc nie masz architektury heksagonalnej. Szczególnie jeżeli mówimy o cieknących frameworkach jak Hibernate. Design jest sterowany potrzebami frameworka a nie np poprawności domeny (przykładowo mutowalne encje z masą setterów vs value objects)

Nawet w wysłanym przeze mnie repo jest użycie @Document wewnątrz domeny, wiele jest też prezentacji mówiących by jednak iść na kompromis i gdy nie trzeba, to po prostu użyć tych adnotacji wewnątrz domeny, zamiast robić mapowania typu dto -> encja biznesowa -> encja bazodanowa, gdzie przy prostym projekcie nie ma różnic między tymi warstwami, albo są one znikome.

Robisz w domenie port o nazwie np. EventPublisher, a w infrastrukturze adapter dostarczający implementacje, np. Springowy ApplicationEventPublisher albo ten websocket. To nie jest żaden osobny moduł, tylko czysto techniczna sprawa.

Odnośnie adnotacji JPA w domenie - nie bądźmy purystami, rzadko kiedy jest sens to rozdzielać (a w przypadku takiego Mongo to już sztuka dla sztuki). Architektura hexagonalna nie jest celem samym sobie, stosujmy tam gdzie to ma sens. W przypadku tego eventPublishera ma zastosowanie, ponieważ umożliwia testowanie z użyciem własnej implementacji in-memory. Bardziej widzę wartość w testowalności właśnie niż w legendarnym rozdzieleniu ubiquitous language od konkretnie technologii - trochę pragmatyzmu ludzie :)

Masz problem, ponieważ planujesz pomieszać komunikację websocket z logiką followersów (domena wycieka). Zrób tak:

@RequiredArgsConstructor
class PostCreator {
    private final PostsProvider postsProvider; <---interface
    private final UsersProvider usersProvider; <---interface
    private final NotificationPublisher notificationPublisher; <---interface

    PostDto createPost(CreatePostCommand command) {
        final var post = Post.of(command);
        final var savedPost = postsProvider.save(post);
        
        final var author = usersProvider.findUser(savedPost.getAuthorId())
        author.getFollowers().forEach(() -> notificationPublisher.publish(new PostCreatedNotification());)

        return savedPost.toDto();
    }
}

Charles_Ray napisał(a):

Robisz w domenie port o nazwie np. EventPublisher, a w infrastrukturze adapter dostarczający implementacje, np. Springowy ApplicationEventPublisher. To nie jest żaden osobny moduł, tylko czysto techniczna sprawa.

Wiele modułów może korzystać z tego publishera, ponieważ w szczególności służy on do asynchronicznej wymiany danych między modułami. Podobnie jak z klientami http - nie będziesz w każdym module powielal implementacji.

Odnośnie adnotacji JPA w domenie - nie bądźmy purystami, rzadko kiedy jest sens to rozdzielać. Architektura hexagonalna nie jest celem samym sobie, stosujmy tam gdzie to ma sens. W przypadku tego eventPublishera ma zastosowanie, ponieważ umożliwia testowanie z użyciem własnej implementacji in-memory. Bardziej widzę wartość w testowalności właśnie niż w legendarnym rozdzieleniu ubiquitous language od konkretnie technologii - trochę pragmatyzmu ludzie :)

Też o czymś podobnym myślałem, ale...
Domena do tego musi wystawić jakiś interfejs, który przyjmie dtosa z domeny.
Infrastruktura może wystawić 1 klasę która implementuje wiele tych interfejsów, z różnych domen, jeżeli cel jest wspólny, tj. wypchnięcie czegos przez WebSocket.
Jeżeli faktycznie użyć tutaj Springowych eventów, to po stronie infrastruktury muszę postawić coś co złapie ten event i wyśle go dalej, czyl np.

public interface EventEmitter {
    public void emitEvent(Event event);
}

public class EventEmitterImpl implements EventEmitter, EventEmitterB... {

    private final ApplicationEventPublisher eventPublisher;

    @Override
    public void emitEvent(Event event) {
        eventPublisher.publishEvent(toApplicationEvent(event));
    }
}

public class EventDispatcher {

    @EventListener(ApplicationEvent.class)
    public void onXYZ(ApplicationEvent xyz) {
        //push to websocket
    }
}

Dochodzi konieczność mapowania eventu z domeny na ApplicationEvent springowy, albo dorzucenie extends ApplicationEvent do dtosa z domeny. Dlatego pomyślałem by to ominąć i owrappować w CompleteableFuture po stronie notyfikacji.

Jaki Springowy event? Robisz swój event domenowy i wysyłasz do rury. Infra może być świadoma domeny, clue jest w tym żeby unikać odwrotnej sytuacji.

Wrappowanie w Future - całkowicie bez sensu, skup się na celu. Żeby mieć Future musisz wprowadzić asynchorniczność, to inny temat niż typy czy zależność domeny od infry. Zobacz jak tutaj jest zrobione: https://github.com/ddd-by-examples/library/blob/master/src/main/java/io/pillopl/library/commons/events/publisher/StoreAndForwardDomainEventPublisher.java

Jeszcze jedno - zainteresuj się wzorcem pub-sub. Na jeden event domenowy (np. PostCreated) możesz mieć wiele reakcji (np. wysłanie tego na websocket, obsluga w innym module, wysłanie maila itd)