You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem description
Currently the username "Anonymous" is hard coded everywhere. When a user signs up, their chosen username should be displayed instead. An anonymous user should still be called "Anonymous".
Possible solutions
With the first solution, the contexts are independent. Any context interested in usernames must subscribe to the events from the Identity context. These events (UserSignedUp and UsernameChanged) are applied to the local copies of the respective context. The WebInterface context has nothing todo but to forward the request to the respective context and return the response back to the user. I like the independence of this approach, but its a lot of common duplication. The second approach pushes these responsibilities to the WebInterface context (see below). Following is a diagram of how this process looks like with a closer look to the Chat context.
With the second solution, the contexts can't answer the username question themselves. It's the responsibility of the WebInterface context to assign usernames to the responses. The WebInterface is anyway the intermediate in every conversation. While the contexts are not independent, I think it's okay to couple the username question to the WebInterface context to gain a little less code. Of course, the first solution is more explicit and explicitness wins over "Don't repeat yourself". Following is a diagram of how this process looks like with a closer look to the Chat context.
The text was updated successfully, but these errors were encountered:
Problem description
Currently the username "Anonymous" is hard coded everywhere. When a user signs up, their chosen username should be displayed instead. An anonymous user should still be called "Anonymous".
Possible solutions
With the first solution, the contexts are independent. Any context interested in usernames must subscribe to the events from the Identity context. These events (UserSignedUp and UsernameChanged) are applied to the local copies of the respective context. The WebInterface context has nothing todo but to forward the request to the respective context and return the response back to the user. I like the independence of this approach, but its a lot of common duplication. The second approach pushes these responsibilities to the WebInterface context (see below). Following is a diagram of how this process looks like with a closer look to the Chat context.
With the second solution, the contexts can't answer the username question themselves. It's the responsibility of the WebInterface context to assign usernames to the responses. The WebInterface is anyway the intermediate in every conversation. While the contexts are not independent, I think it's okay to couple the username question to the WebInterface context to gain a little less code. Of course, the first solution is more explicit and explicitness wins over "Don't repeat yourself". Following is a diagram of how this process looks like with a closer look to the Chat context.
The text was updated successfully, but these errors were encountered: