Take a look at the next post in the series:

http://www.udidahan.com/2009/06/14/domain-events-salvation/

I hope that will clear things up for you.

I have been following this code for a couple of days and trying to understand some of the decision taken to reach this state.

Why is AddGameToCartMessageHandler registering the events? Shouldn’t the purpose of the Handler to handle the event instead of registering.

Thanks,
Azam

Neil,

The difference here is one of meaning. When you need to model an event occuring on the domain itself not any specific entity inside the domain you want to use this pattern. For example, an ObjectChanged event would be on a specific entity. A CustomerCreated event is on the domain itself. Basically the rule of thumb is to determine what makes more sense in the model: if the event argument is a value or an entity itself (or an identifier for the entity). When the former an instance event would make sense, the latter is on the domain itself with the entity being the args.

It is the case that I have multiple events that can be fired within the domain class. In this case I have defined multiple DomainEvents but because the signature is the same, the static actions means that firing one event ultimately fires all event handlers.

Code:
DomainEvent NameChanged = new DomainEvent();
DomainEvent AddressChanged = new DomainEvent();
.
.
using(DomainEvents.NameChanged.Register(NameChangeHandler))
using(DomainEvents.AddressChanged.Register(AddressChangeHandler))
{
person.Name = “Pete”; //Fires Name change event.
//Address Change not firing explicitly.
}
.
.
[ThreadStatic]
private static List<Action> _actions;

public void Raise(E args)
{
foreach (Action action in actions)
action.Invoke(args);
}

NOTE: In this case both registered events are stored in the thread static actions shared by both DomainEvents of the type IPerson. The result is that both NameChange and AddressChange handlers are called.

I simply dropped static altogether for my purposes.

I’m not quite sure I understand the solution you’re proposing.

Sounds interesting – I’ll explore it.

Thanks.

Generally you could introduce a meaningful exception type per event all deriving from a base type (let it be DomainException) and treat those exceptions as messages from the domain to the service layer. As before exceptions that are not derived from DomainException are either bugs or issues and not caught by the interceptor.

Another way is to introduce a disposable class DomainInteractionScope that would contain all the events you need to pass from the domain entities to the service layer. An instance of this class would be passed to the interceptor and would serve as an event container for single message handling.

Also moving all this stuff to the container you would make the domain code much more clear (without the ugly if(…) { DomainEvents.(); return; } stuff).

Does that make sense? (c)

Removing the [ThreadStatic] attribute causes a bug – an action on one thread by user A can call be into a different action previously registered by a different thread by user B.

The overall guidance is that the domain model with its associated events should not be called within the web app itself. Rather, the domain model should be hosted in its own process, an application server if you will, which the web app sends messages to.

Hope that helps.

This creates extensibility and maintainability issues.

Suppose I write another domain object which acts as an aggregate root in a different scenario making use of the current parent as a child. I’d have to remember to redefine that event on my object.

Does that make sense?

What would be the problem with that?

There is (kinda) support for that in the handling of the MessageReceived event of the transport – by setting the order of subscriptions you can do Before and After handling.

It’s actually possible to have another message handler run at the end of the unit of work and do the clean-up for that thread.

Still thinking about the generality of that solution.

I consider having the service layer use the result of one call to the domain to decide if another call to the domain is necessary to be taking domain logic out of the domain.

In your example, I would prefer a single call:

cart.Add(game, policies);

The question is about the connection between the domain and the policies – what are the dependencies between them, how did the service layer get an instance of it, etc.

Maybe you should inject policies into the Cart. The policies are services which perform the checking. Just because the services live outside the domain doesn’t mean the domain is anemic. After all, you are adding intelligence to the domain and can do so using your IoC container.

The service code would look something like:

cart.enforcePolicies(GameOrderPolicies);
if (cart.canAddGame(game))
cart.add(game);
else
Bus.return(cart.brokenPolicies[0].PolicyName)

Your domain only knows that there are certain policies which will be injected in, and those policies must be compliant before before adding a game.

1) conventions++
using(DomainEvents.Register(cartIsFull, gameIsLost)) {

}

I /think/ we can parse out the variable name using the C# 3.0 Expression stuff.

2) using…. the ability of returning something like IDisposableAction is great, but unless there’s great readability to be gained I don’t think I’m in favor of using using this way, is it that much better than something like With.Events(() => { });

The problem with weakrefs, it turns out, is that the thread may run fast enough that garbage colleciton doesn’t occur in time. As such, we may have a dangling delegate being activated from the handling of a previous message by the same thread.

That’s why I need scoping – to simplify cleanup.

And get the same behavior with static invocation.
Same for the Raise() method.

Do you really need scoping in here? Why not support this syntax?

public class AddGameToCartMessageHandler :
BaseMessageHandler
{
public override void Handle(AddGameToCartMessage m)
{
DomainEvents.GameReportedLost+= delegate{
Bus.Return((int)ErrorCoes.GameReportedLost);
};
DomainEvents.CartIsFull += delegate{
Bus.Return((int)ErrorCodes.CartIsFull);
};

using (ISession session = SessionFactory.OpenSession())
using (ITransaction tx = session.BeginTransaction())
using (.Register(cartIsFull))
{
ICart cart = session.Get(m.CartId);
IGame g = session.Get(m.GameId);
 
cart.Add(g);
 
tx.Commit();
}
}
 
}