Notyfikacje w architekturze heksagonalnej

Notyfikacje w architekturze heksagonalnej
AP
  • Rejestracja:około 6 lat
  • Ostatnio:3 miesiące
  • Postów:164
0

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.
edytowany 4x, ostatnio: AngryProgrammer
S9
  • Rejestracja:ponad 10 lat
  • Ostatnio:6 miesięcy
  • Lokalizacja:Warszawa
  • Postów:3573
0

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


"w haśle <młody dynamiczny zespół> nie chodzi o to ile masz lat tylko jak często zmienia się skład"
AP
Chodziło mi o takie podejście https://github.com/jakubnabrdalik/hentai/tree/master/hentai/ z tego rozumiem to chyba nie to samo co ports & adapters?
S9
nie odpisuj w komentarzach
pedegie
  • Rejestracja:około 11 lat
  • Ostatnio:ponad rok
  • Postów:204
0

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

edytowany 4x, ostatnio: pedegie
WS
Kuba Nabrdalik? :D
pedegie
tak, bo to jego repo linkowanie bylo w komentarzu wyzej
nie100sowny
  • Rejestracja:prawie 9 lat
  • Ostatnio:3 dni
  • Lokalizacja:Kraków
  • Postów:402
0
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)


"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"
edytowany 4x, ostatnio: nie100sowny
AP
  • Rejestracja:około 6 lat
  • Ostatnio:3 miesiące
  • Postów:164
0

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

Kopiuj
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;
    }
}
Kopiuj
public class PostCreatedNotification implements Notification {
    @Override
    public Channel getChannel() {
        return Channel.WEB_SOCKET;
    }
}

No i NotificationFacade po prostu deleguje takie wywołanie do

Kopiuj
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.

edytowany 2x, ostatnio: AngryProgrammer
Charles_Ray
  • Rejestracja:około 17 lat
  • Ostatnio:około 4 godziny
  • Postów:1875
0

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 :)


”Engineering is easy. People are hard.” Bill Coughran
edytowany 2x, ostatnio: Charles_Ray
nie100sowny
Pragmatyzm to nie używać JPA.
Charles_Ray
Nie, to jest fałszywa binarność - albo nie używasz JPA, albo jesteś looserem.
nie100sowny
  • Rejestracja:prawie 9 lat
  • Ostatnio:3 dni
  • Lokalizacja:Kraków
  • Postów:402
0

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

Kopiuj
@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();
    }
}

"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"
edytowany 7x, ostatnio: nie100sowny
Charles_Ray
No coś takiego, albo w ogóle followersow wyciągnąć do osobnego modułu i tam reagować na event utworzenie posta. Wtedy tworzenie posta byłoby nieświadome funkcjonalności followersow
AP
  • Rejestracja:około 6 lat
  • Ostatnio:3 miesiące
  • Postów:164
0
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.

Kopiuj
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.

Charles_Ray
  • Rejestracja:około 17 lat
  • Ostatnio:około 4 godziny
  • Postów:1875
1

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)


”Engineering is easy. People are hard.” Bill Coughran
edytowany 2x, ostatnio: Charles_Ray
S9
  • Rejestracja:ponad 10 lat
  • Ostatnio:6 miesięcy
  • Lokalizacja:Warszawa
  • Postów:3573
2

Odnośnie adnotacji JPA w domenie - nie bądźmy purystami, rzadko kiedy jest sens to rozdzielać

Chyba że chcesz mieć niemutowalny obiekt domenowy z jednym konstruktorem zapewniającym spójność danych.


"w haśle <młody dynamiczny zespół> nie chodzi o to ile masz lat tylko jak często zmienia się skład"
Zobacz pozostałe 10 komentarzy
S9
„ Masz metodę która tworzy nowy obiekt na podstawie starego, np. val orderPaid = order.paid()” I w jaki sposób to mi wygeneruje update na bazie danych? Mi chodziło o obiekt domenowy, nie model /encję bazodanową.
nie100sowny
Wejście na proda to dzisiaj robi przedszkolak po bootcamp. Problem to to utrzymać przez lata. To wątek o tym jak robić architekturę hexagonalną, więc gadamy jak to robić dobrze.
Charles_Ray
Nie dogadamy się mistrzowie architektury ;) dobrej nocy
S9
@Charles_Ray: utrzymywałem proda, to już lepiej ;]. I nie, nie sądze że 100% obiektów powinno być niemutowalnych, tylko jakieś 80%. A JPA może mieć czasem sens, ale raczej przy oddzielnej encji bazodanowej.
S9
Jak masz CRUDA to rzeczywiście możesz mieć encje JPA nawet pchaną na fronted, gorzej jak np. masz system bankowy.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.