Czy użytkownik i subskrypcja powinny być w jednej domenie w architekturze sześciobocznej?

Cześć. Zaczynam z hexagonal architecture i jestem na etapie tworzenia pierwszej apki, w której użytkownik może wykupić dostęp do aplikacji płacąc comiesięczną subskrypcje.
Moje aktualne wymagania to:

• rejestracja, podczas której użytkownik wybiera jeden z planów subskrypcji. Po rejestracji użytkownik dostaje darmowego miesięcznego triala, użytkownik nie podaje danych do płatności przy rejestracji
• aktywacja konta przez e-maila
• logowanie
• zmiana hasła
• obsługa całego systemu subskrypcji i płatności tj. obsługa płatności oraz błędów przy pobieraniu opłaty za kolejny miesiąc, dodawanie/zmienianie/usuwanie metod płatności, upgrade i downgrade subskrypcji itd. Implementacja z użyciem stripe

Moje główne pytanie jest takie, czy powinienem zrobić dwie osobne domeny o nazwach np. User i Subscription, czy wszystko powinno być zamknięte w obrębie jednej, większej domeny.
Obie funkcjonalności mają ze sobą trochę wspólnego + są od siebie zależne, to znaczy np. w bazie danych nie zakładam możliwości, że będzie istniał User bez odpowiadającego mu obiektu Subscription i na odwrót. Jak na początku chciałem zaimplementować dwie osobne domeny, to miałem już problem z pierwszym use-casem, bo gdy np. domenie subskrypcji nie uda się utworzyć nowej subskrypcji, to domena użytkownika powinna wycofać wszystkie swoje zmiany i zwrócić błąd do klienta. Nie jestem pewny, czy to jest dobre rozwiązanie tego problemu. Ewentualnie można też zrobić tak, że istnieją dwie osobne domeny, ale np. domena User jest w pełni odpowiedzialna za tworzenie użytkownika i tworzenie subskrypcji z trialem? Z góry dzięki za odpowiedź.

Michał Żłobiński napisał(a):

gdy np. domenie subskrypcji nie uda się utworzyć nowej subskrypcji, to domena użytkownika powinna wycofać wszystkie swoje zmiany i zwrócić błąd do klienta. Nie jestem pewny, czy to jest dobre rozwiązanie tego problemu.

A nie lepiej zrobić sobie coś w stylu event driven, czyli po stworzeniu usera jest event na stworzenie usera i jest sobie handler w domenie subscription który, na podstawie info z eventu, zrobi odpowiadającą subskrypcję? Taka luźna propozycja.

Pinek napisał(a):

A nie lepiej zrobić sobie coś w stylu event driven, czyli po stworzeniu usera jest event na stworzenie usera i jest sobie handler w domenie subscription który, na podstawie info z eventu, zrobi odpowiadającą subskrypcję? Taka luźna propozycja.

To event-driven, to nic innego jak warstwa abstrakcji na te dwa modele.

Michał Żłobiński napisał(a):

Moje główne pytanie jest takie, czy powinienem zrobić dwie osobne domeny o nazwach np. User i Subscription, czy wszystko powinno być zamknięte w obrębie jednej, większej domeny.

Stanardowa odpowiedź: To zależy.

Zależy jak bardzo te dwie "domeny" z punktu widzenia użytkownika są od siebie zależne. Jeśli bardzo, to powinna to być jedna domena. Jeśli mało, to mogą być dwie osobne, ale niekoniecznie.

Michał Żłobiński napisał(a):

Obie funkcjonalności mają ze sobą trochę wspólnego + są od siebie zależne, to znaczy np. w bazie danych nie zakładam możliwości, że będzie istniał User bez odpowiadającego mu obiektu Subscription i na odwrót.

Przy projektowaniu domen nie kieruj się w żadanym stopniu tym jak one są reprezentowane w bazie.

Michał Żłobiński napisał(a):

Jak na początku chciałem zaimplementować dwie osobne domeny, to miałem już problem z pierwszym use-casem, bo gdy np. domenie subskrypcji nie uda się utworzyć nowej subskrypcji, to domena użytkownika powinna wycofać wszystkie swoje zmiany i zwrócić błąd do klienta.

Jeśli takie jest wymaganie klienta, to jest to jednak sygnał, że powinna to być jedna domena.

Michał Żłobiński napisał(a):

jestem na etapie tworzenia pierwszej apki

Jeżeli dopiero zaczynasz tworzyć apkę, to wszystko powinno być w jednej domenie, bo na tym etapie nie wiadomo jeszcze, jakie będą sensowne granice kontekstów.
Nie próbuj teraz tego zgadnąć. Odpowiedź może zależeć od czynników, których teraz nie znacie (ani Ty, ani klient).
Okaże się za 6 m-cy (najwcześniej).

Michał Żłobiński napisał(a):

Moje główne pytanie jest takie, czy powinienem zrobić dwie osobne domeny o nazwach np. User i Subscription

Nie.Czemu w ogóle się tym przejmujesz na tym etapie? Poczytaj o czymś co się nazywa destylacją domeny. To raz.

Po dwa to w tym kontekście nie mówimy o dziedzinach (domenach) tylko o poddziedzinach. Nie wiem czemu wiele osób myli te pojęcia i stosuje jako synonimy. Dziedzina to jest to w czym działa przedsiębiorstwo czyli bankowość, finanse, ubezpieczenia, e-commerce. W ramach dziedzin masz poddziedziny i konteksty ograniczone, gdzie obowiązują różne modele.

Może ten artykuł Sławka Sobótki z magazynu Programista ci trochę rozjaśni https://bottega.com.pl/pdf/materialy/ddd/ddd2.pdf

A co ma Hexagonal architecture do domen/subdomen? Event driven też nie ma tutaj nic do rzeczy na razie. Jak już zrozumiesz jak chcesz rozwiacac problem, to wtedy możesz myśleć o HA, ED etc.

Jeżeli chodzi o DDD, to to wygląda jak 'Generic Subdomains'. Zazwyczaj takich problemów nie rozwiązuje się samemu tylko szuka się oprogramowania 'out of the box' które ten problem rozwiąże. AWS Cognito + Plus coś marketingowe + Adapter między nimi.