Encoding a password sounds like functionality that isn’t very volatile – so you can probably implement it outside the domain model. You’ll probably have an in-memory dictionary of ClientID to EncodingStrategy, which you can look up in your service layer, encode, and then persist.

Not everything needs to be done using a domain model

oops, looks like I did not read the fine prints in details. Sorry for that.
I tried to see if I could salvage all the calls to services in my domain using this design, and there are still a couple of places where I can’t see events to fit elegantly. For example, my User entity need a IEncodePassword (implementation is different from one customer to the other) when one of my user is changing his/her password. Would you still remove that service dependency from the User entity?

Julien

Domain event handlers would be registered in the container at startup. Thus the service layer doesn’t have to register anything. The registering of an action callback is there primarily for testing purposes. Hope that clears it up for you.

Thanks for your great blog, you opened my eyes on so many subjects I have however a problem with this domain event dispatcher: every caller of domain logic that will trigger a given event must register the events themselves. So, the email will be sent when the customer become preferred only if all the methods in the service layer did not forget to register the event everywhere it might be raised.
I would personally add a way to register handler types, so whenever an event occur, the compatible handlers will be instantiated and called, whether the service layer registered the event or not. Then only will be get the assurance the email is sent in every situation the customer becomes preferred.

Or do I miss something?

30: if (actions != null)
31: foreach (var action in actions)
32: if (action is Action)
33: ((Action)action)(args);

Looks like it is trying to invoke a callback. But there is not invoke() function. If it is, do we still need to this? The domain event handler already sent the e-mail out.

Thanks.

The point that you raise is an excellent one, and goes to the heart of designing domain models. It is the responsibility of the aggregate root that its state changes be in-sync with those of its collaborating entities.

In short, the domain model is a tightly coupled set of classes that need to handle this. If they don’t, there’s nothing anybody can do from the outside to fix it.

Designing a good domain model is hard, and ensuring that each aggregate root retains its logical consistency is one of those things that needs to be addressed.

Sorry that there is no silver bullet for that one

One of the problems Domain Events solves is getting domain related fault events out of the domain even in situations where entities may be deeply nested. What happens if a method is called on an aggregate root, it delegates to one of it’s underlying entities, the entity raises a fault event, and the aggregate root, not knowing a fault occurred, changes some of its state and returns? The changes to the aggregate root will be committed right? How do you protect against this type of situation?”

The handling of a domain event wouldn’t send the email directly, instead it would send a message using a bus to another endpoint, and that is the one that would send the email. That would provide for full transactional guarantees. You can look at NServiceBus for those kinds of bus capabilities.

Does that answer your question?

I’m still getting my head round how this will work. In your example, presumably your DoSomething() method would actually look like this:

IsPreferred = true;
DomainEvents.Raise(new CustomerBecamePreferred() { Customer = this });

Suppose you have a handler that fires an email. What happens if the transaction in the service that calls the DoSomething() method fails (the database is down for instance)? Won’t the email still get sent even though the IsPreferred change was not persisted?

Thanks, Jon

Several containers support this out of the box, like Spring and Castle.

Hope that helps.

I’m trying to wire this up to try it out, but I can’t for the life of me work out what IContainer you are using. It looks like the one from NServiceBus 2.0 (with the extension method ResolveAll) but I’ve had a hard time bringing in references that make that work in my project.

This means I can’t get this line of code to compile:
foreach (var handler in Container.ResolveAll<Handles>())

Any help would be appreciated!

Thanks,
Angus

See my post:

http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/

Does that answer your question?

There’s never enough time to do it right, but there’s always enough time to do it again

But I will keep these things in mind next time I have an opportunity to implement them.

Yes, domain events can contain data as well as references to domain objects.

Building a true domain model without having something like an ORM is possible, but you’d best forgo a relational persistence storage as well. Without an actual domain model, it isn’t entirely clear what kind of domain events would be raised.

Even if you did have an ORM, the transactional behavior of processing a domain event would likely require some kind of transactional messaging infrastructure, not to mention other fault-tolerance scenarios which require it.

On what was the decision not to use either of these in your project based?

If I have ResultIsAvailable event, is it ok for it to have a Result property which the listener can access, or should domain events be used for sending messages only? i.e., should it be
“A result is available and here it is”

or just

“A result is available.”

I’d much prefer to use the former if it doesn’t raise any coupling issues.

I’ve been deliberating this methodology as an alternative to having the service layer manage processes that include both domain changes and persistence. This tends to make the domain anemic, but implementing an ORM and a messaging infrastructure are currently not options.

But, following up on David’s post and your reply (#83,84), would you consider it correct to say that using Domain Events is really only proper if you have the kind of transactional messaging infrastructure that you are talking about (MSMQ)?

The actions bit is really only there for testing purposes. There isn’t any practical difference between the two. Looks like it’s time to refactor that out to a different role.

Thanks for the reply! Actually my question is regarding the following code:

if (actions != null)
foreach (var action in actions)
if (action is Action)
((Action)action)(args);

What is the difference between the above code and the following code:

if (Container != null)
foreach(var handler in Container.ResolveAll<Handles>())
handler.Handle(args);

I think Actions is used for domain events and Handle are being used for service oriented events like sending out emails etc.

Is that correct or am I missing something?