I suppose from a certain point of view the task of submitting an order could consist of creating the order as well as notifying any listeners that the order was created.

Your approach also puts the onus on the developer to remember to raise an event anytime that an action performed against the domain is executed that should logically result in the creation of an event. I have a personal aversion to multi-step processes. I guess it feels like the event being raised should be encapsulated with the method invocation related to it.

Thoughts?

p.s. Do you have a link to “Mark”‘s CQRS post? I don’t know which Mark you are speaking of.

I suppose from a certain point of view the task of submitting an order could consist of creating the order as well as notifying any listeners that the order was created.

Your approach also puts the onus on the developer to remember to raise an event anytime that an action performed against the domain is executed that should logically result in the creation of an event. I have a personal aversion to multi-step processes. I guess it feels like the event being raised should be encapsulated with the method invocation related to it.

Thoughts?

p.s. Do you have a link to “Mark”‘s CQRS post? I don’t know which Mark you are speaking of.

@Jarrod
I would handle multi-tenant or session based rules outside of the event publisher in the example. That said, I think you could come up with a dynamic subscription mechanism that could read a ‘ClientSubscriptions Map’ from a data store on session start. Then when EventPublisher.Publish is called, you could have it check the ClientSubscriptions, if the event subscription is present then publish the event. I would just make sure to keep a clear distinction between a system event and a client/customer event.

Thanks for this article and this example. I appreciate how clearly your examples demonstrate a very bare bones, clean, implementation of architectural strategies. It helps that I also use EF POCO, and reviewing yours and Szymon’s code has convinced me to shift to using Unity.

In any case, I wonder if you could do the same for a CQRS architecture in which the client makes no use of the actual domain objects and read/write responsibilities are fully segregated. I find your style of example code to be very easy to follow which makes it much easier to see all of the very smart design decisions being made. Sometimes it’s helpful to see a fully functional application like the one Mark offers in his excellent CQRS post, but I find that when I’m studying an architectural implementation, it’s most helpful for the Domain to be as simple as possible (at least in the initial exploration). I appreciate for instance, that your Order object in this example consists of only an ID and that submitting an Order simply logs the action to a fake logger.

When I first read the comments for this post, I thought some of the responses were a little over the top in their praise. But having spent some time exploring the code, I get it. Thanks for putting this stuff out there. The contributions to the community from the Elegant Code bloggers are much appreciated.

Jason