Asp Identity jako kontekst DDD poddziedziny generycznej

Jak zachować porządek w projekcie?. Jak powinna wyglądać implementacja? Gdzie i jak trzymacie szczegóły dotyczące identyfikacji, roli użytkownika.

Uwierzytelnianie i autoryzacja to infrastruktura, a nie dziedzina aplikacji.

somekind napisał(a):

Uwierzytelnianie i autoryzacja to infrastruktura, a nie dziedzina aplikacji.

Zależy, to może być również warstwa odpowiedzialności. Głównie spotykam się z traktowaniem Dostępu, ról użytkownika jako wspólny mechanizm zwykle trzymany w projekcje Common. Idąc w stronę rdzenia oddzielonego, zaleca się wydzielenie autoryzacji, ról i tp. do osobnej pod dziedziny.

Jestem ciekawy, jak to wygląda w waszych projektach.

Warstwa odpowiedzialności ? Jeśli już to jest właśnie część infrastruktury.
Common to już infrastruktura. Usługi, klasy bazowe wspólne dla całej aplikacji, rozszerzenie frameworka - to jest infra.
Autoryzacja nie jest częścią dziedziny no chyba że robić aplikację do zabezpieczeń.
Role z reguły też nie są częścią domeny.

Użytkownicy jak jak pojmujesz to mechanizm zapewniający obsługę, zabezpieczenie, to jest użytkownik w pojęciu domenowym. W domenie może być Pracownik, Klient, Człowiek a nie nie Użytkownik. Jasne że te dwa 'modele' mogą być ze sobą powiązane, ale to nie jest to samo.

Rozumiem, że dla was każda aplikacja posiada jedną dziedzinę oraz jeden kontekst... A ta konkretna część infrastruktury czego jest częścią.?

Przepraszam nie wyraziłem się jasno. Asp Identity jako część kontekstu DDD poddziedziny generyczne.

Jak dla mnie to używasz jakiejś dziwnej nomenklatury, możesz wyrazić jakoś tak bardziej opisowo o co Ci chodzi?

Bo dla mnie sprawa jest jasna - nieważne ile jest dziedzin i kontekstów, uwierzytelnianie to nadal infrastruktura. Model biznesowy jest wirtualnym odpowiednikiem jakichś rzeczywistych procesów. A to, że w aplikacji jest jakieś uwierzytelnianie nie wynika z modelowania biznesu lecz z tego, że aplikacja jest aplikacją i nie możemy po prostu jak w fizycznym sklepie powiedzieć komuś "pan tu nie stał".

[somekind napisał(a)]:

Jak dla mnie to używasz jakiejś dziwnej nomenklatury, możesz wyrazić jakoś tak bardziej opisowo o co Ci chodzi?

Bo dla mnie sprawa jest jasna - nieważne ile jest dziedzin i kontekstów, uwierzytelnianie to nadal infrastruktura. Model biznesowy jest wirtualnym odpowiednikiem jakichś rzeczywistych procesów. A to, że w aplikacji jest jakieś uwierzytelnianie nie wynika z modelowania biznesu lecz z tego, że aplikacja jest aplikacją i nie możemy po prostu jak w fizycznym sklepie powiedzieć komuś "pan tu nie stał".

No widzisz, ale to zależy czy jesteśmy w sklepie, czy w przychodni oraz w jakim kraju, bo w niektórych nie ma kolejek do lekarzy.

Dlaczego starasz się dalej udowodnić mi, że infrastruktura czy zarządzanie tożsamością użytkownika to jakiś niezależny byt względem dziedziny, czy kontekstu.

Którą z opcji wybierasz.

Kontekst Sklep
application
domain
infra ask for authentication difference context

Kontekst System ER
application
domain
infra ask for authentication difference context

Kontekst Autoryzacja
application
domain all manage Access
infra ask for authentication

Lub

Kontekst Sklep
application
domain with manage Access
infra with authentication

Kontekst System ER
application
domain with manage Access
infra with authentication

Zadałeś pytanie, więc odpowiedziałem zgodnie z prawdą, poza tym nie mam zamiaru niczego udowadniać ani do niczego przekonywać.
Jeśli chcesz sobie myśleć i robić po swojemu oraz dalej nie odróżniać użytkownika od klienta oraz aplikacji od biznesu to tak rób, IDE wszystko przyjmie.

Chory Młot napisał(a):

Którą z opcji wybierasz.

Kontekst Sklep
application
domain
infra ask for authentication difference context

Kontekst System ER
application
domain
infra ask for authentication difference context

Kontekst Autoryzacja
application
domain all manage Access
infra ask for authentication

Lub

Kontekst Sklep
application
domain with manage Access
infra with authentication

Kontekst System ER
application
domain with manage Access
infra with authentication

Kontekst Sklep
application
domain
infra ask for authentication difference context

Kontekst System ER
application
domain
infra ask for authentication difference context

Kontekst Autoryzacja
application
domain all manage Access
infra with authentication

Lub

Kontekst Sklep
application
domain with manage Access
infra with authentication

Kontekst System ER
application
domain with manage Access
infra with authentication

somekind napisał(a):

Zadałeś pytanie, więc odpowiedziałem zgodnie z prawdą, poza tym nie mam zamiaru niczego udowadniać ani do niczego przekonywać.
Jeśli chcesz sobie myśleć i robić po swojemu oraz dalej nie odróżniać użytkownika od klienta oraz aplikacji od biznesu to tak rób, IDE wszystko przyjmie.

Że co...? Jak na razie to ty nie odróżniasz warstw aplikacji od pod dziedziny czy kontekstu.

Niewątpliwie masz rację.
Pewnie dlatego ja tworzę systemy, a Ty pytasz jak to robić. :)

somekind napisał(a):

Niewątpliwie masz rację.
Pewnie dlatego ja tworzę systemy, a Ty pytasz jak to robić. :)

Tak, pewnie dalej klepiesz te swoje procedury na trzech warstwach stąd te twoje pojęcie o kontekstach aplikacji.

Proszę książkowy przykład. github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_identityaccess/src/main/java/com/saasovation/identityaccess
Jakbyś dalej nie odróżniał infra od kontekstu czy dziedziny.

ok, ale spójrz do czego służy przytoczony przez ciebie przykład - ta aplikacja po za autoryzacją nie robi nic. Taki jest jej cel, główne/jedyne zadanie.
Czyli że jej dziedziną jest zapewnienie autoryzacji użytkowników.
Dlatego modele nawet powinny odnosić się do Użytkowników, Rol i Grup Użytkowników.

Slepiec napisał(a):

ok, ale spójrz do czego służy przytoczony przez ciebie przykład - ta aplikacja po za autoryzacją nie robi nic. Taki jest jej cel, główne/jedyne zadanie.
Czyli że jej dziedziną jest zapewnienie autoryzacji użytkowników.
Dlatego modele nawet powinny odnosić się do Użytkowników, Rol i Grup Użytkowników.

To jest Kontekst Ograniczony, zawierający oprócz warstwy infrastruktury oraz aplikacji warstwę domeny, której kontekst ograniczony jest rozwiązanie problemu dziedziny. Gdybyś się bliżej przyjrzał temu kontekstowi autoryzacji to byś zauważył, że korzysta on usługi otwartego hosta, czyli komunikuje się za pomocą języka opublikowanego z innymi kontekstami.

Krwawy Orzeł napisał(a):

Slepiec napisał(a):

ok, ale spójrz do czego służy przytoczony przez ciebie przykład - ta aplikacja po za autoryzacją nie robi nic. Taki jest jej cel, główne/jedyne zadanie.
Czyli że jej dziedziną jest zapewnienie autoryzacji użytkowników.
Dlatego modele nawet powinny odnosić się do Użytkowników, Rol i Grup Użytkowników.

To jest Kontekst Ograniczony, zawierający oprócz warstwy infrastruktury oraz aplikacji warstwę domeny, której kontekst ograniczony jest rozwiązanie problemu dziedziny. Gdybyś się bliżej przyjrzał temu kontekstowi autoryzacji to byś zauważył, że korzysta on usługi otwartego hosta, czyli komunikuje się za pomocą języka opublikowanego z innymi kontekstami.

Niemożliwe ktoś przeczytał tę książkę brawo Ty.

Tej książki nie czytałem (notabene zamówiłem ją kilka dni temu), mam za to dość na świeżo książkę Evansa.
To co pisz jest prawdą, ale nie zmienia to faktu że to jest jedyny BC tej aplikacji i jest to aplikacja do autoryzacji użytkowników - taki jest BC i taka jest cała domena.
A to czym się komunikuje... może nawet wysyłać listy pocztą polską czy używać RFC 1149, to nie ważne.
ps: Kod przeglądałem na komórce w tramwaju :P

Slepiec napisał(a):

Tej książki nie czytałem (notabene zamówiłem ją kilka dni temu), mam za to dość na świeżo książkę Evansa.
To co pisz jest prawdą, ale nie zmienia to faktu że to jest jedyny BC tej aplikacji i jest to aplikacja do autoryzacji użytkowników - taki jest BC i taka jest cała domena.
A to czym się komunikuje... może nawet wysyłać listy pocztą polską czy używać RFC 1149, to nie ważne.
ps: Kod przeglądałem na komórce w tramwaju :P

No to otwórz ją na stronie 386 mapy kontekstów, następnie na stronie 474 rdzeń oddzielony, 469 spójne mechanizmy, na koniec 417.

Jeśli na pytanie związane z tytułem Asp Identity jako część kontekstu DDD poddziedziny generycznej. Wy mi odpowiadacie, że autoryzacja to nie jest część dziedziny tylko infrastruktury. To nie rozumiecie w ogóle, o czym mówię, ponieważ nie przeczytaliście tej książki ze zrozumieniem lub w ogóle jej nie czytaliście.

Powinienem również zapytać co technologia użyta do komunikacji ma się do języka opublikowanego czy usługi otwartego hosta.

Niech to zdanie da wam do myślenia.

To jest Kontekst Ograniczony, zawierający oprócz warstwy infrastruktury oraz aplikacji warstwę domeny, której kontekst ograniczony jest rozwiązanie problemu dziedziny.

Ej, ale to w tej magicznej książce pełnej mądrych słów i wybitnych teorii, nie ma odpowiedzi na to jak zachować porządek w projekcie?
Jakoś wierzyć mi się nie chce.

[Slepiec napisał(a)]:

ok, ale spójrz do czego służy przytoczony przez ciebie przykład - ta aplikacja po za autoryzacją nie robi nic. Taki jest jej cel, główne/jedyne zadanie.
Czyli że jej dziedziną jest zapewnienie autoryzacji użytkowników.
Dlatego modele nawet powinny odnosić się do Użytkowników, Rol i Grup Użytkowników.

Czyli istnienie tej aplikacji nie ma sensu bez dziedziny głównie. Wiec jest to poddziedzina pomocnicza, a zarazem generyczna ponieważ jest powtarzalna w wielu podobnych systemach.

A dziedzina główna może mieć wiele tych pod dziedzin.

[somekind napisał(a)]:

Ej, ale to w tej magicznej książce pełnej mądrych słów i wybitnych teorii, nie ma odpowiedzi na to jak zachować porządek w projekcie?
Jakoś wierzyć mi się nie chce.

Wydaje mi się, że już wystarczająco dużo na temat tej magicznej książki powiedziałeś.

No to otwórz ją na stronie 386 mapy kontekstów, następnie na stronie 474 rdzeń oddzielony, 469 spójne mechanizmy, na koniec 417.

Zamówiłem tę książkę, od wczoraj czeka w Paczkomaty