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

Re: [domaindrivendesign] Issue with Publish/Subscribe

Expand Messages
  • Nuno Lopes
    Hi, Events reflect what gets changed as a consequence of executing an operation against an Aggregate. In other words, that is the axis of change for an event
    Message 1 of 8 , Feb 1, 2012
    View Source
    • 0 Attachment
      Hi,

      Events reflect what gets changed as a consequence of executing an operation against an Aggregate. In other words, that is the axis of change for an event (fact), not what the supplier needs to know. They aren't DTO's, they aren't even Messages.


      On Jan 31, 2012, at 11:23 PM, mikehamedani wrote:

       

      Hello,

      I was having a chat with a friend about publish/subscribe but he raised an issue that I had no answer to. Consider this scenario:

      Our publisher publishes message X. Tomorrow we need to add a new subscriber but this new subscriber needs more data than what is currently included in X. So, we'll have to modify the publisher "because of this new subscriber", which affects the loose coupling of these components.

      He also mentioned that now that you want to release this subscriber, you should also manage to release the new version of publisher with the new message format at the same time, which leads to release management headaches.

      What is the right approach to address these issues?

      Mike


    • remyfannader
      Events are meant to happen once; they are associated to changes in the state of objects or activities. They can be known directly or though messages but
      Message 2 of 8 , Feb 1, 2012
      View Source
      • 0 Attachment
        Events are meant to happen once; they are associated to changes in the
        state of objects or activities. They can be known directly or though
        messages but messages are not to be confused with referred events. And
        event descriptions are not supposed to change (except for expected
        ones).
        http://caminao.wordpress.com/when-representations-are-to-be-used/events-\
        2/
        http://caminao.wordpress.com/how-to-implement-symbolic-representations/p\
        atterns/functional-patterns/event-patterns/
        Remy.
        --- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...>
        wrote:
        >
        > Hi,
        >
        > Events reflect what gets changed as a consequence of executing an
        operation against an Aggregate. In other words, that is the axis of
        change for an event (fact), not what the supplier needs to know. They
        aren't DTO's, they aren't even Messages.
        >
        >
        > On Jan 31, 2012, at 11:23 PM, mikehamedani wrote:
        >
        > > Hello,
        > >
        > > I was having a chat with a friend about publish/subscribe but he
        raised an issue that I had no answer to. Consider this scenario:
        > >
        > > Our publisher publishes message X. Tomorrow we need to add a new
        subscriber but this new subscriber needs more data than what is
        currently included in X. So, we'll have to modify the publisher "because
        of this new subscriber", which affects the loose coupling of these
        components.
        > >
        > > He also mentioned that now that you want to release this subscriber,
        you should also manage to release the new version of publisher with the
        new message format at the same time, which leads to release management
        headaches.
        > >
        > > What is the right approach to address these issues?
        > >
        > > Mike
        > >
        > >
        >
      • Sławek
        If specific listener needs more data than it s its problem to gain that data. For example call some service that provides additional data. We can assume that
        Message 3 of 8 , Feb 1, 2012
        View Source
        • 0 Attachment
          If specific listener needs more data than it's its problem to gain that data.

          For example call some service that provides additional data. We can assume that Event contains some IDs or sth that is sufficient to load some additional data in specific listener.

          As mentioned in previous posts: Event is not a DTO. Ideally object that fires event reveals what he wants to reveal, not what is demanded by the outer wold. But of course in brutal world sometimes it's better to break decoupling and abstraction by revealing more (leaky abstraction) in sake of performance:/

          S³awek Sobótka
          http://code.google.com/p/ddd-cqrs-sample/
        • mikehamedani
          Interesting point. I completely agree that publisher should decide what to reveal, rather than being dictated by the other world. Ok, now here is the
          Message 4 of 8 , Feb 1, 2012
          View Source
          • 0 Attachment
            Interesting point. I completely agree that publisher should decide what to reveal, rather than being dictated by the other world.

            Ok, now here is the challenge. If you've read about Udi Dahan's view of SOA, there is no synchronous request/response between services in his view, as this increases the coupling between services.

            Now, if Service A publishes an event but Service B needs more data than is available in the event, it will have to query Service A for this additional data. I can't think of any other ways to obtain the additional data if synchronous request/response is not allowed and events are not going to be changed to address this need.

            What's your advice on this?









            --- In domaindrivendesign@yahoogroups.com, Sławek <slawomir.sobotka@...> wrote:
            >
            > If specific listener needs more data than it's its problem to gain that data.
            >
            > For example call some service that provides additional data. We can assume that Event contains some IDs or sth that is sufficient to load some additional data in specific listener.
            >
            > As mentioned in previous posts: Event is not a DTO. Ideally object that fires event reveals what he wants to reveal, not what is demanded by the outer wold. But of course in brutal world sometimes it's better to break decoupling and abstraction by revealing more (leaky abstraction) in sake of performance:/
            >
            > S³awek Sobótka
            > http://code.google.com/p/ddd-cqrs-sample/
            >
          • eben_roux
            Hello Mike, I don t think Udi meant that you should *never* use request/response in a system. It probably relates more to the use of a service bus where we
            Message 5 of 8 , Feb 1, 2012
            View Source
            • 0 Attachment
              Hello Mike,

              I don't think Udi meant that you should *never* use request/response in a system. It probably relates more to the use of a service bus where we would never want to use it to query data (a la request/response) or perform any temporal coupling in the form of request/response.

              Let's rather use the term component and not service. So Component A publishes an event and subscriber Component B requires more than that present in the message. How we get that data is what is important. This does introduce some temporal coupling but it is OK since we are handling the call in a service bus endpoint where we have automatic retries and other good stuff.

              You could query the data store for Component A or go through some integration layer such as a web-service. It is absolutely no problem.

              Regards,
              Eben
            • sweetlandj
              If the other system also publishes events, then it could simply be a matter of eventual consistency. System A publishes an event that contains part of the
              Message 6 of 8 , Feb 2, 2012
              View Source
              • 0 Attachment
                If the other system also publishes events, then it could simply be a matter of eventual consistency. System A publishes an event that contains part of the information. Then system B publishes one or more event(s) that complete the picture. Eventually the consumer will have all the data.


                --- In domaindrivendesign@yahoogroups.com, "mikehamedani" <mike.hamedani@...> wrote:
                >
                >
                > Interesting point. I completely agree that publisher should decide what to reveal, rather than being dictated by the other world.
                >
                > Ok, now here is the challenge. If you've read about Udi Dahan's view of SOA, there is no synchronous request/response between services in his view, as this increases the coupling between services.
                >
                > Now, if Service A publishes an event but Service B needs more data than is available in the event, it will have to query Service A for this additional data. I can't think of any other ways to obtain the additional data if synchronous request/response is not allowed and events are not going to be changed to address this need.
                >
                > What's your advice on this?
                >
                >
                >
                >
                >
                >
                >
                >
                >
                > --- In domaindrivendesign@yahoogroups.com, Sławek <slawomir.sobotka@> wrote:
                > >
                > > If specific listener needs more data than it's its problem to gain that data.
                > >
                > > For example call some service that provides additional data. We can assume that Event contains some IDs or sth that is sufficient to load some additional data in specific listener.
                > >
                > > As mentioned in previous posts: Event is not a DTO. Ideally object that fires event reveals what he wants to reveal, not what is demanded by the outer wold. But of course in brutal world sometimes it's better to break decoupling and abstraction by revealing more (leaky abstraction) in sake of performance:/
                > >
                > > S³awek Sobótka
                > > http://code.google.com/p/ddd-cqrs-sample/
                > >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.