I don't understand the issue.. instead of bus.Publish(events) why not foreach (@event in events) bus.Publish(@event) ?
On Aug 5, 8:57 am, Udi Dahan <thesoftwaresimpl...@udidahan.com> wrote: > Should an implementation detail of your command side cause such issues at > the interface level? > > I would think not - in which case, maybe the implementation needs to be > re-evaluated. Don't assume what the structure of your aggregates is supposed > to be, nor the events they expose. Let it evolve from the needs of the > interface. > > Regards, > > -- Udi Dahan > > From: rhino-tools-dev@googlegroups.com > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols > Sent: Thursday, August 05, 2010 6:38 PM > To: rhino-tools-dev@googlegroups.com > Subject: Re: [rhino-tools-dev] Re: rhino rsb subscription harvesting > > @Jason, Thanks for jumping in :) > I am not using Udi's implementation of DomainEvents.Raise<TEvent>(..). I am > familiar with that approach, but am instead doing event sourcing. What this > means is during the course of an operation one or more events are applied to > the Aggregate Root. Upon the commit of a UnitOfWork those events are > serialized to an event store after which they are published on a bus. Not > all usages of Domain Events are synchronous operations on the query store. > They can be but I have pulled those out of process. > In a separate process lives a series of Denormalizers which subscribe to > these events. But the domain itself may also subscribe to these events for > purpose of communicating across Bounded Contexts or perhaps contributing to > a saga. > My posting didn't have to do with any of this, though :). > > Instead, it was related to the faulty assumption that calling Publish on > more than one message should assume that every endpoint in that batch of > messages can be derived from the first message in the batch. That works for > Send, but not Publish. When I am calling Send, I am safely making > assumptions about the endpoint to which I am Sending those > messages...namely, that they will go to the same place. When I call Publish, > that assumption should not be made. > > On Thu, Aug 5, 2010 at 7:31 AM, Jason Meckley <jasonmeck...@gmail.com> > wrote: > > Mike, if I'm following the discussion correctly the problem has become > confusion between messages on RSB and handlers for domain events. > > messaging (RSB) is an asynchronous action. you can batch messages > together and all the messages in the batch are send to the endpoint > defined by the 1st message in the batch. that is by design to keep > transactional boundaries. if you need to send multiple messages to > various endpoints you need to send them separately, each it's own > transaction. > > domain events are synchronous operations that would occur within the > same transaction as the message(s) being processed. for example here > is a consumer to process an order > void Consume(ProcessOrder message) > { > session.Get<Order>(message.OrderNumber).Process(); > > } > > the Process() method on order might look like this > void Process() > { > //validate order is ready for processing > //change the state of order and/or order lines > > DomainEvents.Raise<OrderProcessed>(this); > > } > > where DomainEvents.Raise is a static facade to instantiate and execute > the various OrderProcessed. for example you may have the following > handlers for order processing > SendInvoiceToCustomer : IHandler<OrderProcessed> > ShipProductsToCustomer : IHandler<OrderProcessed> > DecreaseInventoryOfItemsOnTheOrder : IHandler<OrderProcessed> > UpdateATableUsedForReporting : IHandler<OrderProcessed> > > all of these handlers would execute immediately, within the same > transaction, when the order is processed. and if any of these > operations would fail the entire transaction would rollback as well. > Some of these handlers may call the service bus to send another > message but each of those messages is yet another transaction > independent of actually processing the order. > > I hope this helps rather than adds confusion or another tangent. From > what I have read, understanding this distinction may help explain why > RSB works the way it does, where domain events fit into the > architecture and how the 2 are used to solve different problems. And > why atomic transactions to various endpoints doesn't work (or is a bad > idea). > > On Aug 5, 9:03 am, Mike Nichols <nichols.mik...@gmail.com> wrote: > > > @Udi > > I am not sure I understand. I am using event sourcing, so I persist events > > on the domain side for rehydration of Aggregates, etc (domain-side). The > bus > > publishes these events, which are subscribed to by interested query-side > > denormalizers. > > > On Thu, Aug 5, 2010 at 12:40 AM, Udi Dahan > > <thesoftwaresimpl...@udidahan.com > > > > > > > > > > wrote: > > > I think that the reason you're running into difficulty is that your > > > persisting data on the command side that should have only been persisted > on > > > the query side. > > > > Cheers, > > > > -- Udi Dahan > > > > -----Original Message----- > > > From: rhino-tools-dev@googlegroups.com > > > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols > > > Sent: Thursday, August 05, 2010 1:09 AM > > > To: Rhino Tools Dev > > > Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting > > > > @Udi > > > I am persisting the events. After the events have been persisted they > > > are put on the bus for publication. > > > My initial concern here though was about the assumption that the first > > > message in a batch is the sole provider of subscription details for an > > > entire batch of messages. It seems like a user should just Publish a > > > batch of messages on a bus and not be concerned about who is > > > subscribed to them. > > > > To be clear this code from the PublishInternal method in the > > > defaultservicebus is what I am discussing.What this code is saying is > > > that if you have two messages in a batch being Published, and each one > > > is subscribed to by different endpoints, then the second message in > > > the batch will not get published. That seems unpredictable to me: > > > private bool PublishInternal(object[] messages) > > > { > > > if (messages == null) > > > throw new ArgumentNullException("messages"); > > > > bool sentMsg = false; > > > if (messages.Length == 0) > > > throw new MessagePublicationException("Cannot publish > > > an empty message batch"); > > > object msg = messages[0]; > > > IEnumerable<Uri> subscriptions = > > > subscriptionStorage.GetSubscriptionsFor(msg.GetType()); > > > foreach (Uri subscription in subscriptions) > > > { > > > > transport.Send(endpointRouter.GetRoutedEndpoint(subscription), > > > messages); > > > sentMsg = true; > > > } > > > return sentMsg; > > > } > > > > m > > > > On Aug 4, 9:51 am, Udi Dahan <thesoftwaresimpl...@udidahan.com> wrote: > > > > Mike, > > > > > The case of CQRS usually has the service layer publishing the events > in > > > > response to commands, domain events has nothing to do with it. If > you're > > > > talking about event-based persistence on the command-side, again, > domain > > > > events have nothing to do with the bus. > > > > > Cheers, > > > > > -- Udi Dahan > > > > > -----Original Message----- > > > > From: rhino-tools-dev@googlegroups.com > > > > > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols > > > > Sent: Wednesday, August 04, 2010 4:46 PM > > > > To: Rhino Tools Dev > > > > Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting > > > > > If I have 5 events that took place on my aggregate root during the > > > > course of a unit of work. My understanding is that the root represents > > > > a transactional boundary. So I publish the events on the bus as a > > > > batch. The subscriber (in this case, denormalizers for events that > > > > write to a database) will go through each event and update the > > > > database, ideally in a single transaction so that if one of the > > > > handlers fails, then they all fail. > > > > As I think about it, I am not sure why that is so important other than > > > > the convenience of having NHib in a single session and cut down on the > > > > number of roundtrips. But I realize this is an impl detail that > > > > shouldn't be the driver. > > > > > @Udi - I actually went back and forth on whether to publish these > > > > individually or not, so it is helpful to hear from you on this. Can > > > > you see why I would consider the batch a single unit though? If you > > > > are using a denormalizer you always only send one event at a time to > > > > that endpoint? > > > > > On Aug 4, 6:35 am, Udi Dahan <thesoftwaresimpl...@udidahan.com> wrote: > > > > > Then I'm afraid it sounds like you're not using DomainEvents the > right > > > way > > > > - > > > > > each event from the domain should be a discrete domain occurrence. > > > > > > -- Udi Dahan > > > > > > -----Original Message----- > > > > > From: rhino-tools-dev@googlegroups.com > > > > > > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols > > > > > Sent: Wednesday, August 04, 2010 3:45 PM > > > > > To: Rhino Tools Dev > > > > > Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting > > > > > > I am publishing the DomainEvents from my domain. These events are > > > > > subscribed to by 1 (or more report) services that update the db > state > > > > > from those events. > > > > > @Udi - I could publish them one at a time, yes, but I'd rather the > > > > > whole batch fail since they represent a unit of work from my > > > > > domain...I don't want some messages to succeed and others to fail > > > > > leaving the db in an odd state. > > > > > > On Aug 4, 5:39 am, Ayende Rahien <aye...@ayende.com> wrote: > > > > > > What is the scenario in which you would want to publish a message > > > batch? > > > > > > And publishing doesn't use the owners, it uses the subscriptions > > > list. > > > > > > I think that I had the wrong idea in mind about what we are > talking > > > > about, > > > > > > yes, for publish, that would make sense, but I still want to know > > > what > > > > > your > > > > > > scenario is. > > > > > > > On Wed, Aug 4, 2010 at 3:33 PM, Mike Nichols > > > > > <nichols.mik...@gmail.com>wrote: > > > > > > > > Isn't that the difference between Publish and Send though? > > > > > > > 'Publishing' an event in my mind doesn't carry any assumption > > about ... > > read more » -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to rhino-tools-...@googlegroups.com. To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
