WIP: cqrs #25
WIP: cqrs #25
Conversation
|
BIs auf das angesprochene Problem finde ich es gut so 👍 |
main.go
Outdated
| router.HandleFunc("/users", userService.Register).Methods("POST") | ||
| router.HandleFunc("/users/register/{registrationID}", userService.Activate).Methods("GET") | ||
| router.HandleFunc("/users/do/register", userHandler.Register).Methods("POST") | ||
| router.HandleFunc("/users/do/activate", userHandler.Activate).Methods("POST") |
There was a problem hiding this comment.
das ist ziemlich doof. der nutzer soll ja einfah nur aus der mail auf einen link klicken. POST ist da schwierig, deswegen hatte ich es mit "/users/register/{registrationID} gemacht.
There was a problem hiding this comment.
ich hätte den gui link so gemacht, und den service link nicht
There was a problem hiding this comment.
Also soll aus der regiustrierungsmail ein link auf die gui gehen, die dann den post macht?
|
User-Endpunkt findAll -> Nur für registrierte und aktive Nutzer, |
|
Meeting Endpunkt findAll -> Reduced Ansicht liefern. Sonst sind es zu viele Infos |
|
Meeting erstellen -> Nur registrierte und aktive User |
|
SetBuyer -> Darf nur der creator |
|
SetPlace -> Darf nur der creator |
|
Ist was mir jetzt so aufgefallen ist. |
|
Die Prüfung ob man einen usecase darf scheint für mich einer der ersten Schritte im usecase selber zu sein, im Gegensatz zur Prüfung im web handler. So beantwortet es natürlich eher nur die frage: Was muss erfüllt sein um diesen usecase zu starten - und nicht: Was darf ich alles als . So wie's jetzt ist wirkt es für näher am fachlichen, für die technische Frage/Überblick gibt's ja die Diagramme mit Aktoren. |
|
Und kannst du die Stellen mit duplicate code markieren? |
|
@peter-mueller kann ich machen. Bin aber erstmal nicht am PC die nächsten Tage, kannst also auch erstmal mergen und ich mach dann ein issue auf :p |
@FabianWilms so will ich die handler weiter auftrennen, kannst ja mal drüber schauen ob das so ok wäre und ob du wo bedenken hast