You can use NServiceBus to create an application server – see the async pages sample for an example of how this would look.

Create an application server as you suggest (not really sure what that would look like; NT Service perhaps?) to get around the ThreadStatic problem in ASP.NET

OR

Move the responsibility of publishing events outside of the domain (for example: in an MVC controller, as is done in the two articles I linked to above).

Are there any other approaches which you are aware that I might be missing?

If there aren’t any other options, are you aware of any good resources on creating an application server?

I’ve read quite a few blogs on CQRS recently, but the technique seems ephemeral at best at this point.

Keeping the metrics in a different persistent object model is a good idea. Sending to another endpoint is something that you would do using something like NServiceBus – ergo a multi-process solution.

You could shortcut this somewhat by having the other endpoint be hosted in a separate appdomain in the same process – would that help?

Those metrics don’t need to be handled in the same transaction as the new post or topic, right? In which case, I’d recommend sending a message from your domain event handler to another endpoint, and it will be the one doing those calculations.

When a new post is added to a topic or a new topic is added to a forum, I’d like to cache some summary information (last post title for a topic/forum, last poster for a topic, total topics, total replies per thread and forum, etc.). I initially thought about caching these in the parent object, but I’m leaning more towards having new entities for ForumMetrics and TopicMetrics that get updated when a DomainEvent is fired from the containing object.

However, reading through the comments above, it seems you’re suggesting staying away from calling into repositories from DomainEvent handlers. Do you have a suggestion for how I might persist this summary information otherwise?

I’d be quite suspicious about BCs that always need to be consistent with each other – this high temporal coupling indicates that there is a strong semantic coupling as well.

Thank you for taking the time to answer my question. After some thought I’m having difficulty determing if the *need* to be consistent. I’m using NHibernate as my persistence mechanism. I’ve wrapped NHibernate’s ISession in a custom UnitOfWork class.

My application service does the following:

using(IUnitOfWork uow = UnitOfWork.Create())
{
IRepository repository = ….

Driver driver = repository.GetById(driverIdToMerge);

driver.Merge(driverId);

uow.PersistAll();
}

My probem is that I can’t have the domain events actually be raised until the session is flushed and all commands have been sent to the database because the 2nd BC involved expects those changes to be there.

What I’ve done is this. I’ve taken your DomainEvents class and added some functionality to essentially store all the events it has been sent from the domain objects. When PersistAll() is called above it starts a transaction, flushes the session and commits the changes.
Then within the same method it raises all of the events in the DomainEvents class by calling a static method named RaiseAll(). This currently works because the changes have been committed and the 2nd BC can act appropriately.

I don’t like the way this is implemented. It doesn’t hurt anything if the 2nd BC is executed, it just doesn’t make any sense for it to. I’d like the entire thing to run under one transaction if possible.

Now, finally for my question. The only way I see to have the seperate BC’s be executed under the same transaction is if I pass the session into the handler. Is this OK to do? Something about this just doesn’t seem right. Thanks again for your help.

The question is whether you need both your BCs to be consistent with each other at *all* times – ergo in the same transaction.

If the answer is yes, then you absolutely do want the event to be raised and handled in the same transaction – you’d also be deploying both BCs together.

If the answer is no, then you should use some kind of message bus between the BCs. The handler for the domain event would publish a message using the bus, and that would be enlisted in the same transaction – thus is the first BC rolled back, the message wouldn’t be sent. The second BC would be invoked by the bus when the message arrives at its queue where its handling would then be done in a separate transaction.

In message number 120 above, Lars asks about how to access the data if the event is fired before the commit. I didn’t understand your response. Maybe my situation is different so I’ll explain.

I have 2 BCs. One context deals with the merging of employee information. I’d like to fire a domain event specifying that the employee was merged. I’d like the 2nd BC to react to this event. The issue is that the data won’t be committed at that point, and this data that changed is vital to the 2nd BC to react.

Am I going down the wrong path by attempting to use domain events? Is there another solution you could suggest?

Yes, domain events are a useful way to keep to BCs in sync. The specific scenario you’re raising (calling a web service) is one where you’d probably be better off by introducing messaging between your BCs so that the non-deterministic latency of the web service call doesn’t end up slowing down your system.

I am developing a web-ordering system, where submitted orders are sent to a remote web service (controlled by another part of the business). I’m thinking of two primary bounded contexts: Local and Remote (actual names are more appropriate to the business context, but just keeping things simple here). When an order is saved in the Local context, I’ve been thinking about using Domain events to trigger the order being submitted in the Remote context to the web service.

Does a domain event seem like the right approach in this case? And, more generally, does communicating between bounded contexts using domain events seem reasonable?

I’m not very positive about the benefits of event sourcing so I’m not sure I’m in a position to answer your questions. One reason is that I don’t think that the majority of raw data in the system (like customer first name, last name, phone numbers, etc) actually need to be in the domain model when doing CQRS.

On comand/event separation. Is it not equally valid to say

A customer requested a change to their address as it is to say A customer requests a change to their address.

My reasoning is by the time it gets to your domain model, it is in the past.

I am seriously looking at CQRS in combination with all the other DDD goodies. In particular Event sourcing.

My question is, given the separation between commands (things you want to happen) and events, what actually happened. If you were building a framework to give the ability to reverse/replay/compensate. In an event, would you record the full state of the object, before/after, both or only what changed with before/after or simply what changed after.

I am specifically lookin at this from the reverse/replay/compensate and audit trail point of view.

Compensate is something I have added. For situations such as you have reverved a hotel room via a Gateway to another system and your transaction fails, thus you need to compensate for the failure with a system that is not in your transaction boundary.

I have already implemented recording commands, and am wondering if you would also record events, and if so, exactly what you would record.

Domain events get handled by service layer objects in the same process which usually send out other messages – as such, we want those messages to be sent (or not) in the same transactional context.

Is there any specific reason for handle domain events within the same transaction scoping DoSomething?

Nuno

Don’t take each of these blog posts as a full architectural picture – these are designed to nudge people in a certain direction. There are so many ways that people abuse domain models that the goal is to get them to see a different perspective.

Thank you
kenshin

If you’ve noticed in my later blog posts, I’ve mentioned how many domain models may ultimately end up as long-running processes (aka sagas) in which case the events raised are indeed published using a message/service bus.

I don’t quite understand why should we use the code you presented in your article unless we want to build an EventManager from scratch. Seems to me that this is equivalent to using a message bus from within the domain object every time there is a need to raise an event, something similar to

jmsService.send(destination, message)

jmsService would be equivalent to DomainEvents

Am I missing something ?

Thank you

Actions from the UI are modeled as intention-revealing commands – not events. These commands indicate what is desired, but the system may ultimately reject. Events represent something that already happened.

You might want to read my posts on CQRS for information about this:

http://www.udidahan.com/2009/12/09/clarified-cqrs

Since the domain events are ultimately raised in-memory, there’s no reason why it wouldn’t work in a hosted web app environment.