Loading ...
Sorry, an error occurred while loading the content.

Communication between Bounded Contexts

Expand Messages
  • wonderfulworldofpingpong
    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
    Message 1 of 6 , May 23, 2013
    View Source
    • 0 Attachment
      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.
    • Ramin Tavassoli
      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
      Message 2 of 6 , May 24, 2013
      View Source
      • 0 Attachment
        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 domaindrivendesign@yahoogroups.com, "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.
        >
      • wonderfulworldofpingpong
        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
        Message 3 of 6 , May 24, 2013
        View Source
        • 0 Attachment
          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 domaindrivendesign@yahoogroups.com, "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 domaindrivendesign@yahoogroups.com, "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.
          > >
          >
        • Ramin Tavassoli
          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
          Message 4 of 6 , May 25, 2013
          View Source
          • 0 Attachment
            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 domaindrivendesign@yahoogroups.com, "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 domaindrivendesign@yahoogroups.com, "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 domaindrivendesign@yahoogroups.com, "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.
            > > >
            > >
            >
          • Ramin Tavassoli
            ... Should say ...the call to the User app service for *authorization*... Ramin
            Message 5 of 6 , May 25, 2013
            View Source
            • 0 Attachment
              Correction:

              > If you want, you can abstract away the call to the User app service for authentication by having an IAuthorizationService ...

              Should say "...the call to the User app service for *authorization*..."

              Ramin

              --- In domaindrivendesign@yahoogroups.com, "Ramin Tavassoli" <rtavassoli@...> wrote:
              >
              > 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 domaindrivendesign@yahoogroups.com, "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 domaindrivendesign@yahoogroups.com, "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 domaindrivendesign@yahoogroups.com, "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.
              > > > >
              > > >
              > >
              >
            • wonderfulworldofpingpong
              Thank you Ramin for the reply.
              Message 6 of 6 , May 25, 2013
              View Source
              • 0 Attachment
                Thank you Ramin for the reply.

                --- In domaindrivendesign@yahoogroups.com, "Ramin Tavassoli" <rtavassoli@...> wrote:
                >
                > Correction:
                >
                > > If you want, you can abstract away the call to the User app service for authentication by having an IAuthorizationService ...
                >
                > Should say "...the call to the User app service for *authorization*..."
                >
                > Ramin
                >
                > --- In domaindrivendesign@yahoogroups.com, "Ramin Tavassoli" <rtavassoli@> wrote:
                > >
                > > 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 domaindrivendesign@yahoogroups.com, "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 domaindrivendesign@yahoogroups.com, "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 domaindrivendesign@yahoogroups.com, "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.
                > > > > >
                > > > >
                > > >
                > >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.