Rejestra i konto użytkownika aplikacji a model domenowy

0

Siema siema,
mam pewna zagwozdkę. Mianowicie o to co z zarządzania użytkownikiem powinno być, a co nie powinno być w ramach modelu domenowego, albo inaczej mówiąc jak połączyć "Usera" z np. Spring Security z model konta.

  1. Jak wygląda sprawa z tworzeniem użytkownika? Są na to tez jakieś reguły biznesowe, czy powinna być ona przeprowadzana przez serwisy biznesowe, czy powinniśmy trzymac ją od nich jak najdalej
    2)Jak e zmienianiem hasła?
    Czy domena powinna w ogóle wiedziec o czymś takim jak hasło? Czy powinno być tak że zmiana hasła jest "poza" domeną konta jako szczegół zależny od np. frameworka, a w ramach domeny konta użytkownika powinniśmy np. zmieniać tylko emaile, jakieś ustawienia domyślne itp?
2

Jeżeli konto użytkownika ma tylko służyć do zalogowania do aplikacji, a nie jest np. częścią procesu sprzedaży kont użytkowników to w ogóle niech będzie poza domeną. Zostaw tą część jako zwykły CRUD.
Konto użytkownika to szczegół techniczny. Zaraz się może okazać że już nie rejestruje się u Ciebie tylko loguje przez Facebooka, a aplikacja od strony biznesowej będzie działać tak samo.

2

Jeśli podczas pierwszej rejestracji, użytkownik ma otrzymać bon rabatowy, to jest to część domeny. Dlatego warto jest zostawić w domenie interface odpowiadający logowaniu użytkownika, zgodnie z architekturą porty adaptery. Nieważne czy jest to CRUD, ważne jest to czy architektura ma być elastyczna względem widzimisię klienta i czego się spodziewamy w przyszłości. Zwykle wszystko zaczyna się od prostego CRUD'a a najczęściej kończy się na spaghetti.

8

To nie użytkownik dostaje kod rabatowy tylko klient. Klient jak najbardziej jest częścią domeny, użytkownik niekoniecznie. I lepiej nie łączyć tych koncepcji w jedną, właśnie po to, aby uniknąć spaghetti.

1

No właśnie też tak sądzę - chyba najlepiej po utworzeni encji usera "technicznego" odplalic jakis UseCase domenowy np SendDiscountCodeUseCase i szczegół techniczny wie o domenie a nie odwrotnie

0

To nie użytkownik dostaje kod rabatowy tylko klient. Klient jak najbardziej jest częścią domeny, użytkownik niekoniecznie. I lepiej nie łączyć tych koncepcji w jedną, właśnie po to, aby uniknąć spaghetti.

Tak nie koniecznie, ale użytkownik może być np. częścią domeny generycznej, a klient może dziedziczyć po użytkowniku, tak nie wolno łączyć tych koncepcji.

No właśnie też tak sądzę - chyba najlepiej po utworzeni encji usera "technicznego" odplalic jakis UseCase domenowy np SendDiscountCodeUseCase i szczegół techniczny wie o domenie a nie odwrotnie

Ja raczej myślałem o podpięciu się pod event jak RegisteredNewClient.

1

No i tu wychodzą problemy z mikroserwisami. HTTP nie wspiera dziedziczenia, więc ciężko osiągnąć porządne spaghetti, w którym klient po użytkowniku dziedziczy.

1

No i tu wychodzą problemy z mikroserwisami. HTTP nie wspiera dziedziczenia, więc ciężko osiągnąć porządne spaghetti, w którym klient po użytkowniku dziedziczy.

Nie mam pojęcia co domena ma wspólnego z protokołem komunikacji.

Poza tym mylisz pojęcia uogólnienie to nie to samo co łączenie.

W kontekście forum moderator może być użytkownikiem.
W kontekście jakiejś korporacji moderator może być współpracownikiem.

W ogóle mówisz o czymś z innej beczki.

Wytłumacz mi o co ci chodzi na przykładzie jakiś mikroserwisów, które są za bramą i do komunikacji używają np. gRPC.

1
MisterMaster napisał(a):

Nie mam pojęcia co domena ma wspólnego z protokołem komunikacji.

Oczywiście nic. Przykład rozdzielnych aplikacji miał ukazać błędność mieszania konceptów. Jeśli są dwa serwisy, to nie zrobi się w nich patologicznego dziedziczenia klienta z użytkownika, co byłoby możliwe we wspólnej bazie kodu.
I nie ma też powodu, aby nie dziedziczyć nawet jeśli nie używa się mikroserwisów.

W kontekście forum moderator może być użytkownikiem.
W kontekście jakiejś korporacji moderator może być współpracownikiem.

Nie być lecz pełnić rolę.

0
somekind napisał(a):
MisterMaster napisał(a):

Nie mam pojęcia co domena ma wspólnego z protokołem komunikacji.

Oczywiście nic. Przykład rozdzielnych aplikacji miał ukazać błędność mieszania konceptów. Jeśli są dwa serwisy, to nie zrobi się w nich patologicznego dziedziczenia klienta z użytkownika, co byłoby możliwe we wspólnej bazie kodu.
I nie ma też powodu, aby nie dziedziczyć nawet jeśli nie używa się mikroserwisów.

W kontekście forum moderator może być użytkownikiem.
W kontekście jakiejś korporacji moderator może być współpracownikiem.

Nie być lecz pełnić rolę.

Pod tym microserwisem w warstwie domeny może być wiele dziedziczeń, może być również używane różnego rodzaju słownictwo np. User.

A czy można zrobić microservice "TeamService" gdzie value object'y TeamLeader, Developer, Tester, będą dziedziczyć po klasie abstrakcyjnej Worker, a Team będzie aggregatorem? Czy według ciebie lepiej byłoby nadać rolę pracownikowi używając enuma?

1
MisterMaster napisał(a):

Pod tym microserwisem w warstwie domeny może być wiele dziedziczeń, może być również używane różnego rodzaju słownictwo np. User.

Może być wiele dziedziczeń, chociaż lepiej, gdyby były tylko tam gdzie to niezbędne.
Ale nie o to chodzi - po prostu użytkownik aplikacji i klient to zupełnie odmienne koncepcje, i nie należy ich mieszać, nawet jeśli w rzeczywistości jest to jedna osoba.

A czy można zrobić microservice "TeamService" gdzie value object'y TeamLeader, Developer, Tester, będą dziedziczyć po klasie abstrakcyjnej Worker, a Team będzie aggregatorem?

No można, tylko nie wiem po co, bo podajesz jakiś abstrakcyjny przykład bez kontekstu. A poza tym członków zespołu raczej chcielibyśmy identyfikować, więc value objecty tu nie bardzo pasują. No chyba, że to ma być symulator Tata Consulting Services albo Comarchu, wtedy pracownicy nie potrzebują tożsamości.

Czy według ciebie lepiej byłoby nadać rolę pracownikowi używając enuma?

Nie wiem czy enuma, enumy są mało elastyczne - dodanie nowej roli wymaga skompilowania aplikacji. Często jest to niepożądane.

0

Może być wiele dziedziczeń, chociaż lepiej, gdyby były tylko tam gdzie to niezbędne.
Ale nie o to chodzi - po prostu użytkownik aplikacji i klient to zupełnie odmienne koncepcje, i nie należy ich mieszać, nawet jeśli w rzeczywistości jest to jedna osoba.

Czyli według ciebie użytkownik nie jest hiperonimem słowa klient w kontekście sklepu internetowego?
Dlaczego użytkownik strony z kuponami jak np. picodi.com nie może dostać bon rabatowy na wybraną sieć sklepów, po pierwszej rejestracji?

No można, tylko nie wiem po co, bo podajesz jakiś abstrakcyjny przykład bez kontekstu. A poza tym członków zespołu raczej chcielibyśmy identyfikować, więc value objecty tu nie bardzo pasują. No chyba, że to ma być symulator Tata Consulting Services albo Comarchu, wtedy pracownicy nie potrzebują tożsamości.

Dlaczego Value Object nie może być identyfikatorem?

Nie wiem czy enuma, enumy są mało elastyczne - dodanie nowej roli wymaga skompilowania aplikacji. Często jest to niepożądane.

Czym byś go zastąpił?

2

Jak przykładowo rozróżnić:
Użytkownik systemowy-> zawiera wszystkie informacje "systemowe" (uprawnienia, status itp)
Użytkownik płatności -> metody płatności
Klient -> zawiera informacje o zamówieniach osoby, rabaty itp
i tu można wymyślać dalej

I tak, można powiedzieć, ze to to samo. Chodzi tu, żeby rozdzielić te informacje i korzystać z nich tylko tam gdzie trzeba, a nie wyciągać jakiś uber wielki obiekt zawsze.

0
MisterMaster napisał(a):

Czyli według ciebie użytkownik nie jest hiperonimem słowa klient w kontekście sklepu internetowego?

Według mnie zamodelowany w sklepie internetowym klient służy do innych rzeczy niż uwierzytelnianie czy autoryzacja.

Dlaczego użytkownik strony z kuponami jak np. picodi.com nie może dostać bon rabatowy na wybraną sieć sklepów, po pierwszej rejestracji?

To nie użytkownik strony tylko klient sklepu.

Dlaczego Value Object nie może być identyfikatorem?

Pewnie może nim być, ale nie ma sensu, aby sam był identyfikowany przez identyfikator.

Czym byś go zastąpił?

Np. odpowiednim modelem ról i uprawnień, które mogą być dynamicznie zmieniane i przechowywane np. w bazie danych.

0

Według mnie zamodelowany w sklepie internetowym klient służy do innych rzeczy niż uwierzytelnianie czy autoryzacja.

To nie jest odpowiedź na moje pytanie.

To nie użytkownik strony tylko klient sklepu.

Jak zapewne wiesz, używane słownictwo jest zależne od domeny, a zachowania zależne od kontekstu.

Pewnie może nim być, ale nie ma sensu, aby sam był identyfikowany przez identyfikator.

Moim zdaniem przechowywanie encji w agregacie było by bezsensu, ponieważ ja nie chcę wymazać z systemu pracowników po usunięciu team'u.

Np. odpowiednim modelem ról i uprawnień, które mogą być dynamicznie zmieniane i przechowywane np. w bazie danych.

Czyli użytkownik, który jest autorem postu powinien mieć role autor? A dlaczego Value Object opisujący autora postu nie może się nazywać Author i zawierać tylko jego identyfikator?

--

Udzielenie rabatu poprzez bon rabatowy to nie jest to samo co nabycie usługi lub towaru, więc nie wiem, czemu się tak czepiłeś tego klienta.
A jeśli chcę dać użytkownikowi forum 50zł w prezencie, za napisanie miliona postów, to wtedy on jest klient forum, czy jak?

1
MisterMaster napisał(a):

To nie jest odpowiedź na moje pytanie.

To jest temat poruszany w tym wątku, jeśli chcesz dyskutować o czymś innym, to załóż nowy wątek.

Jak zapewne wiesz, używane słownictwo jest zależne od domeny, a zachowania zależne od kontekstu.

Owszem, cały czas właśnie o tym piszę. Logowanie się do sklepu i robienie w nim zakupów to dwa różne konteksty.

Czyli użytkownik, który jest autorem postu powinien mieć role autor?

Niczego takiego nie sugerowałem. Role użytkownika są związane z autoryzacją, nie domeną.

A dlaczego Value Object opisujący autora postu nie może się nazywać Author i zawierać tylko jego identyfikator?

Pewnie dlatego, że VO nie zawierają identyfikatorów.

0

Pewnie dlatego, że VO nie zawierają identyfikatorów.

https://github.com/VaughnVernon/IDDD_Samples_NET/blob/master/iddd_agilepm/Domain.Model/Products/ProductId.cs

Strona 376
https://ptgmedia.pearsoncmg.com/images/9780321834577/samplepages/0321834577.pdf

Widzę lubisz sobie sam strzelać w stopę

Ta wypowiedź też dużo tłumaczy...

To jest temat poruszany w tym wątku, jeśli chcesz dyskutować o czymś innym, to załóż nowy wątek.

Owszem, cały czas właśnie o tym piszę. Logowanie się do sklepu i robienie w nim zakupów to dwa różne konteksty.

Ale co mnie obchodzi robienie zakupów, jak chcę komuś dać bon rabatowy.
Jeśli bawisz się w gaslighting to daj sobie spokój, na mnie to nie działa.

Niczego takiego nie sugerowałem. Role użytkownika są związane z autoryzacją, nie domeną.

To w jaki sposób wyrazisz w domenie osobę która zajmuje się moderacją, skoro jak mówisz nie możesz nadać jej roli, ponieważ nie jest to częścią domeny?

1
MisterMaster napisał(a):

Pewnie dlatego, że VO nie zawierają identyfikatorów.

https://github.com/VaughnVernon/IDDD_Samples_NET/blob/master/iddd_agilepm/Domain.Model/Products/ProductId.cs

No i to jest właśnie Value Object, który jest identyfikatorem. Kilka postów temu napisałem, że tak może być.

To w jaki sposób wyrazisz w domenie osobę która zajmuje się moderacją, skoro jak mówisz nie możesz nadać jej roli, ponieważ nie jest to częścią domeny?

Po prostu nie będę tego robił.

0

No i to jest właśnie Value Object, który jest identyfikatorem. Kilka postów temu napisałem, że tak może być.

Zapytam jeszcze raz nawiązując do mojej ostatniej wypowiedzi:
"A dlaczego Value Object opisujący autora postu nie może się nazywać Author i zawierać tylko jego identyfikator?"

Dlaczego Value Object o nazwie Author nie może zawierać identyfikator użytkownika który napisał owego posta?

Po prostu nie będę tego robił.

A czy forum będzie już częścią domeny? To jak będziesz dodawać moderatora do forum?

2
MisterMaster napisał(a):

No i to jest właśnie Value Object, który jest identyfikatorem. Kilka postów temu napisałem, że tak może być.

Zapytam jeszcze raz nawiązując do mojej ostatniej wypowiedzi:
"A dlaczego Value Object opisujący autora postu nie może się nazywać Author i zawierać tylko jego identyfikator?"

Dlaczego Value Object o nazwie Author nie może zawierać identyfikator użytkownika który napisał owego posta?

Na moje oko klepacza crudów mieszasz tu dwie rzeczy:

  • AuthorId jak jest niemutowalne i ma dobrze napisane porównywanie to jest Value Objectem
  • Author jest encją bo ma ID (ale nie jest ID) więc nawet jak jest niemutawalny to nie może być Value Obiectem

Pomijam problem że Author który zawiera samo ID (AuthorId) ma średni sens bo autor powinien mieć jeszcze jakieś imię lub Id do innej encji która ma brakujące dane

0

Na moje oko klepacza crudów mieszasz tu dwie rzeczy:

  • AuthorId jak jest niemutowalne i ma dobrze napisane porównywanie to jest Value Objectem
  • Author jest encją bo ma ID (ale nie jest ID) więc nawet jak jest niemutawalny to nie może być Value Obiectem

Jeśli pobieram identyfikator z kontekstu/domeny "indentyfikacja dostępność" to w domenie/kontekście forum może to być Autor, ponieważ w forum nie ma żadnego aggregata Autor. W tym momencie nie ma to znaczenia czy to jest AutorId czy Autor.

Pomijam problem że Author który zawiera samo ID (AuthorId) ma średni sens bo autor powinien mieć jeszcze jakieś imię lub Id do innej encji która ma brakujące dane

Jeśli czegoś tam brakuje, to można to dodać np. imie, nazwisko.
Od strony domeny interesuje nas utrwalanie stanu ("tranzakcja" = aggregat). Post jest agregatem, gdyby autor był encją, to po usunięciu postu usunąłbyś autora z systemu.
A dlaczego w Value Object zwykle implementuje się IComparable, oraz nadpisuje Equals? A co to jest tak naprawdę ten identyfikator encji?

Jeśli chodzi
@somekind

Moim zdaniem kontest / domena forum może zawierać użytkownika, a kontest / domena sklep może zawierać klienta, obydwaj mogą otrzymać bon rabatowy.

On chyba łapie mnie za słówka i z góry sobie coś do moich wypowiedzi dopowiada.

@KamilAdam
Moim zdaniem problem klepaczy krudowych jest taki, że nieprzyczytali ani jednej książki ani drugiej o DDD.
A co myślisz o wykorzystaniu "Aktywnego Agregata" w kontekście porblemu autora postu, w której książce była o tym mowa?

2
MisterMaster napisał(a):

Od strony domeny interesuje nas utrwalanie stanu ("tranzakcja" = aggregat). Post jest agregatem, gdyby autor był encją, to po usunięciu postu usunąłbyś autora z systemu.
A dlaczego w Value Object zwykle implementuje się IComparable, oraz nadpisuje Equals?

Pytasz bo nie wiesz czy pytasz bo mnie egzaminujesz?
Value Object nadpisuje Equals bo z definicji jest to obiekt nie posiadający tożsamości i dwa VO są sobie równe jeśli wszystkie ich pola są sobie równe. W Javie (i prawdopodobnie C#) nie da się zrobić tego z automatu bez dodatkowych narzędzi lub bibliotek. Ale w niektórych językach VO są wbudowane. W Kotlinie są Data Classy, Scali - Case Classy, a w Haskellu dodaje się do typu deriving (Eq)

A co to jest tak naprawdę ten identyfikator encji?

Jest to Value Obiekt (czasem niestety zestaw VO) który definiuje tożsamość Encji. W bazie danych temu VO odpowiada klucz główny

@KamilAdam
Moim zdaniem problem klepaczy krudowych jest taki, że nieprzyczytali ani jednej książki ani drugiej o DDD.
A co myślisz o wykorzystaniu "Aktywnego Agregata" w kontekście porblemu autora postu, w której książce była o tym mowa?

Przeczytali ale nie wszystko pamietają więc nie będę opowiadać o rozdziałach których nigdy w praktyce nie użyłem

BTW Encje i VO są starsze niż DDD więc nie trzeba czytać oświeconych książek żeby wiedzieć co to.

1

Nie wystarczy przeczytać, trzeba jeszcze zrozumieć. Chociażby to, że CRUD to nie jest miejsce na DDD.

0

Nie wystarczy przeczytać, trzeba jeszcze zrozumieć. Chociażby to, że CRUD to nie jest miejsce na DDD.

Żeby zrozumieć trzeba praktykować.

@KamilAdam
Mój znajomy, który jest szanującym się klepaczem krudowym, reaguje bardzo emocjonalnie na słowo DDD on się chyba tego słowa boi. Dla niego wszystko jest krudem np. Forum to CRUD, Magazyn to CRUD, Sklep to CRUD i tak dalej.

1 użytkowników online, w tym zalogowanych: 0, gości: 1