public static class DomainEvents
{
private static IContainer container;

public static void Initialize(IContainer newContainer)
{
if (newContainer == null) throw new ArgumentNullException(“newContainer”);
container = newContainer;
}

public static void Register(Action callback) where T : IDomainEvent
{
container.GetInstance().Register(callback);
}

public static void ClearCallbacks()
{
container.GetInstance().ClearCallbacks();
}

public static void Raise(T domainEvent) where T : IDomainEvent
{
container.GetInstance().Raise(domainEvent);
}
}

I got the idea from here:
http://jasondentler.com/blog/2009/11/simple-domain-events/

I like it better because I don’t have to use the static ObjectFactory class explicitly. Any thoughts on this?

Looks cool! Yeah, the nested container is just a way to provide scoped lifecycle of things. Great for context objects, and can be used instead of Hybrid stuff in some places.

public static class DomainEvents
{
public static void Register(Action callback) where T : IDomainEvent
{
ObjectFactory.GetInstance().Register(callback);
}

public static void ClearCallbacks()
{
ObjectFactory.GetInstance().ClearCallbacks();
}

public static void Raise(T domainEvent) where T : IDomainEvent
{
ObjectFactory.GetInstance().Raise(domainEvent);
}
}

Where the DomainEventsController (for lack of a better word) is the DomainEvents implementation and can be wired up as having a Hybrid lifecyle. I was also thinking that using ObjectFactory.TryGetInstance could be used instead of GetInstance. This could give us more flexibility within our tests.

You got me thinking about nested containers now. I’ve been using the Hybrid lifecycle. Wonder if I’m doing that wrong?

Any ideas?

Funny you should ask this, as we’re looking at the exact same issues. Static gateways just don’t play as nicely with IoC, so we’re also examining our options. Right now, domain event handlers are instantiated by the container, so we do have SOME control over lifecycle.

However, we can’t do things like nested containers.

I’m wondering how you manage the shared state (the actions) within the static DomainEvents class for asp .net web applications? Udi places the [ThreadStatic] attribute on the actions but this is not a good idea when in the context of an asp .net web application. I’m thinking of using Structure Map’s ObjectFactory to get the DomainEvents class and have that class wired up with a Hybrid lifecycle.

How do you handle this issue?

I use protected setters for lists and objects and I do something like this:

private AuditDate _auditDate = new AuditDate();

protected set
{
if (value == null) throw new ArgumentNullException(“value”);
_auditDate = value;
}

Eliminates the need to do any null checking, reduces likelyhood of bugs. In the declaration where I’m instantiating the AuditDate, if the setter was public allowing the caller to set a new object then I would have set the initial value to be a NullAuditDate using the null object pattern.

To me this is the next logical step after protecting your setters. The objects using the NullObject pattern will always fail persistence since the ORM doesn’t track an object of that type.

No, not really. What would be the connection?

@ryzam

In my experience, events only arise when someone cares about something that happened. A command may generate no events, or several, it just really depends on those “When” requirements.

If I’m not mistaken, there was a discussion in DDD group either entity can have reference to repository/service or not. Some of them reject this approach even though if we are using Dependency Injection to supply the instantiate object.

If we look into this Domain Events implementation the concept is almost similar where your entity some how will also have to use external component to do a job.

But, personally I agree with Domain Events solution, keep up ..

Another question, does every command we send to entity need to have DomainEvent?

Example: If we have command RegisterLicenseCustomer, do we also have LicenseCustomerRegistered as DomainEvents?

While that’s certainly possible, you’re now coupling yourself to implementations of handlers. With an event, I don’t need to know who, or how many folks care about this event.