I liked the article and I like the idea of domain events but I wonder how much better it is than using DDD Specifications.

IMO if you submit the aggregate for persistence and apply the Specification to the returned persisted one it will work exactly the same.

Anyway they are to separate concerns.

Also I have some questions about the second part of the article. It looks to me like a kiss in the EF ass. :-)

Santos

Specifications ??

How could you do the following from the article with specifications? I am not really seeing the connection?

public class CustomerBecamePreferredHandler : Handles <customerbecamepreferred
{

public void Handle(CustomerBecamePreferred args)

{

  // send email to args.Customer

}

}

Also, the only reference to the EF is a picture where your choice of ORM is really a peripheral matter. Was there somthing else?

Well, one way to do it, of the top of my mind:

public class OrderService

{

    IOrderRepository mRepository;

    IMailService mMailService

    public OrderService(IOrderRepository repository, IMailService mailService)

    {

        if(repository == null)

            throw new ...

        if(mailService==null)

            throw new ...

        mRepository = repository;

        mMailService = mailService;

    }


    public void Submit(IOrder order)

    {

        order = mRepository.AddNew(order);

        if(order.PreferredSpecification.IsSatisfiedBy(order))

            mMailService.SendMail(order.Customer)

    }

} 



public class OrderPreferredSpecification : Specification

<order
{

    public override bool IsSatisfiedBy(Order order)

    {

        // Build your predicates here and return true/false

    }   

}



public class Order

{

    //...Other properties


    public PreferredSpecification { get; }

}

BTW in regards to EF he could have used ORM then!

Santos

That would send the customer an order every time they submit an Order. Not just when they become preferred. Also, Assume that their are multiple ways that a customer may become preferred. The specification may tell you if a customer meets some criteria. But it won't tell you when that customer change happened.

Specification-- Does something Meet some criteria

Domain Event- Something Interesting Happened.

Usages

If (Specification.IsSatisfiedBy(something))

    Do Something 

Whenever (Something Interesting Happens)

  Do Something (1.Log it happened,2Publish It happened on a bus,3, Let some other object know it happened, etc...)

The two are Orthogonal IMO.

Wow, I really should proofread prior to hitting submit especially if typing while having another conversation.

Corrections:

send the customer an email every time they submit an order

assume that there

criteria, but

meet some criteria?

----All the really weird capitalization

Erik

Santos,

That looks really bad. Imagine that we have 10 such conditions.

Are you going to have 10 if statements? Or would you rather have it in the a more loosely coupled way?

Oren,

In that case you could encapsulate all the other predicates in the IsSatisfiedBy in a more general/composite specification. But usually those conditions are within the Aggregate or are accessible from the specification.

If there is a better way I am open to use it!

Santos

Ayende,

Yeah the thing I really like about it is that it allows you to be much more OCP with your Domain Model and services while still adding Interesting behavior to Domain Event Handlers.  The number of reasons for both your service class and Domain classes to change just reduced considerably when you follow his guidance in the article.

This coupled with the way he does different models for different bounded contexts (or no model at all in some bounded contexts if it is not justified) likely reduces the urge to move domain behavior out of your models.

Erik

I often hear that you should only use the domain model pattern for complex scenarios. What is a good pattern for the "simple" cases? How do you know if you have a domain model or just a persistant object model? I find encapsulating business rules in "domain" objects to be beneficial even in simple cases. Am I missing something here?

While I agree with all of your article, still DDD is not the only way to go. My only point is while for DB apps : DDD is great for managing complexity, still there are other cases to not use DDD.

Oren,

Specifications have worked fine for me but I don't know too much about Domain Events yet. As I as said in my first post I just wonder how much better it is than using Specifications. As soon as I have a chance I'll give it a try. For now I just take your word for it.

Santos

I think Erik has clearly mentioned above the difference between Specification and Domain Event:

"Specification-- Does something Meet some criteria

Domain Event- Something Interesting Happened."

Well, "John" in that case I was responding to Oren and I do not need a translator!

Thanks,

Santos

Santos,

I didn't mean to offend anyone.

I thought u might have missed it and just pointed it out.

chill out man ;)

John,

No problem man just a "small overreaction" :-)

Santos

Ayende, (as you are officially known to master Castle MK/Windsor ;),

could you point or elaborate on how Event Registration Facility may help to wire such design without friction?

I've not used it yet but thinking of triggering all components satisfying IEventHappeningListener <tevent,> seems interresting.

But there are some rules to think about such as ordering of the handlers, being atomic or compounded, etc.

So this look like a tricky issue when dealing with larger than sample code but still my aim for "project+1", just because the provided decoupling is great for evolutivity/maintability