Re: Communication between Bounded Contexts

Yup, that's pretty much how I would do it. The Game BC should know how to start a game, the User/Authorization BC should know how to authorize things. And the application service layer should coordinate the responsibilities.

If you want, you can abstract away the call to the User app service for authentication by having an IAuthorizationService (or using IMembershipProviders and IRoleProviders - eg. default Forms Authentication in ASP.Net).

But in the end the implementation for IAuthorizationService will make the call to the User app service, so to keep things simple you can do it the way you describe perfectly well.

Enjoy
Ramin

--- In [email protected], "wonderfulworldofpingpong" <varghese.pallathu@...> wrote:
>
> Ramin, thanks for the reply.
> 
> This can be done this way from your description. The UI sends a request to StartGame/CreateGame. This request is managed by a Game app service. The Game app service calls the User app service for authentication. Once it is authenticated, the game service calls the Game BC to create the game.
> 
> Am I right?
> 
> --- In [email protected], "Ramin Tavassoli" <rtavassoli@> wrote:
> >
> > Neither 1, nor 2, nor 3. Also no domain service calls into the User BC.
> > 
> > Your question is about authentication and authorization. These are usually orthogonal to the domain. The caller of "StartGame" (assuming a game is started - ubiquituous language of the domain - and not created - CRUD) would need to be authenticated, and the StartGame command can then be authorized.
> > 
> > This happens outside of the Game BC, before the domain is involved. Authentication can be done by the remote facade (if you have one), which authenticates the credentials (username/password, token, certificate, etc.) sent alongside the command.
> > 
> > Once authenticated, the StartGame command can be authorized. In order to do this, the authenticated credentials may need to be translated into a user of the User BC, and then the User BC can be queried for the necessary privileges - IsGroupLeader?.
> > 
> > Note the "queried". This does not have to be a consistent call, it is usually perfectly ok to go to the query model for things like authorization.
> > 
> > Once the responsibilities are cleanly separated, you can start optimize authorization if needed - eg. caching users privileges -, and even completely replace it with a new authorization mechanism without having to change the Game BC.
> > 
> > Hope this helps
> > Ramin
> > 
> > --- In [email protected], "wonderfulworldofpingpong" <varghese.pallathu@> wrote:
> > >
> > > I have few different Bounded Contexts in the domain. The validation of a CRUD operation is built in each Bounded Context. 
> > > 
> > > For example, I can create an entity called GAME only if the person creating it is a Group Leader. 
> > > 
> > > I have two Bounded Contexts (BC) in this example. One is the 'Game BC' and the other is the 'User BC'. To solve the problem, in the 'Game BC', I have to make a domain service call like IsGroupLeader() to the 'User BC' before proceeding on creating the Game.
> > > 
> > > I don't think this type of communication is recommended by DDD. I can have a 'User' entity also in the 'Game BC'. I don't like this approach because it leads to code duplication of IsGroupLeader() in every Bounded Context that I have.
> > > 
> > > My questions are:
> > > 
> > > 1. Should I use Domain events where the Game BC has to send an event to the User BC asking the status of the User? With this approach, I don't make a synchronous call like IsGroupLeader() but an event called is_group_leader. Then the Game BC has to wait for the User BC to process the event and return the status. The Game BC will create the Game entity only after the User BC process the event.
> > > 
> > > 2. Add a new entity called User to the Game BC and use that entity instead of accessing the same entity from the other BC.
> > > 
> > > 3. The other approach is the 'Game BC' sends an event when the GAME entity is created. That is processed by the 'User BC' and the 'User BC' sends another message back to the 'Game BC' to complete the entity creation.
> > > 
> > > Any idea appreciated.
> > >
> >
>




------------------------------------