Comments on: Container-friendly domain events

By: Aluminium Kozijnen

Aluminium Kozijnen — Wed, 25 May 2011 12:33:00 +0000

I think here we can change that design whatever we want.. Very useful one..

By: Joe

Joe — Fri, 20 May 2011 16:59:00 +0000

Thanks. I figured it out from your other post on using StructureMap registries to find generic interfaces. In my app startup, SM finds my listener interfaces, then I add them to the static DomainEvents container of handlers, and the rest is easy. Thanks for your great posts on the subject!

By: Jimmy Bogard

Jimmy Bogard — Thu, 19 May 2011 03:02:00 +0000

It’s still a static call to DomainEvents.Raise, that’s all. That part didn’t change from the link in the post above.

By: Joe

Joe — Mon, 16 May 2011 18:38:00 +0000

I feel really stupid asking, but could you post an end-to-end example of this? I’m not seeing how your domain model still doesn’t need a reference to your handler container.

By: Joe

Joe — Mon, 16 May 2011 18:38:00 +0000

I feel really stupid asking, but could you post an end-to-end example of this? I’m not seeing how your domain model still doesn’t need a reference to your handler container.

By: bogardj

bogardj — Wed, 04 Aug 2010 12:43:39 +0000

@Udi

That’s step 2 in a refactoring towards messaging, this is the midway point. Originally this code had no concept of a message, transactional boundaries or anything. Step 1 – convert a batch process to create a message from each line, but keep the processing synchronous. Step 2 – this message broker would instead just fire off the message.

By: Udi Dahan

Udi Dahan — Wed, 04 Aug 2010 10:55:36 +0000

Why would you be processing a batch of messages together to begin with if each one is its own unit of work? You could just send each message in the batch to another endpoint and then the message boundary already gives you all the scoping you need.