This would most likely be communicated via email.

Great article, I just have one question in the SubmitOrder example where the business logic is moved to the Purchase method and a separate handler would handle if the order exceeds the limit of unpaid orders how would this be communicated to the user? I was wondering if the UI would be subscribed to this event and could then display a message.

Thanks,
Mike

It means a lot to me to hear that the time I invest in simplifying things pays off – so thanks very much for your kind words.

The scenario you’re asking about sounds like a pure entity-manipulation story, one that doesn’t quite fit the purpose of CQS. Trying to shoe-horn it, it would be clear that the Query side would be responsible for filling in the dropdown, but creating an entity is rarely a command.

See this blog post for more information:

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

Hope that helps.

as always your article is a great source of knowledge. Although I’m stunned by the simplicity of your Query/Domain separation which seems to me to be the most readable CQS example I’ve ever seen, I have one doubt which is:

presume that in UI, on a form, you have a dropdown, which should be filled with the types of the entity you are creating. Where these types should come from? Query or Domain? If there are from Query, how the mapping from a simple int-key to the Domain object should be done?

Happy to hear that it’s working out well for you.

Great article! This is an excellent way to keep both the service layer and the domain model pure. We’re using this clean up our service layer. We’re moving all the “do external stuff” to handlers on domain events instead of having it in the service layer. This leaves the service layer very thin, it basically just manages transactions and calls a domain object. Keep up the good work, it has really made a difference for the better in my current project.

In the example you give, I’d probably have Customer.ApproveLicense, which internally changes the LicenseStatus, raises an event – CustomerLicenseStatusChanged, which would be caught by a handler, which then sends the email.

Does that answer your question?

1. Do you move all the business process responsiblity to handler? Example:

Admin can change Customer LicenseStatus and notification email will send to that customer.

public class Customer
{
public LicenseStatus CurrentLicenseStatus {private set; get;}

public void ChangeLicenseStatus(SendEmailWhenStatusChanged msg)
{
//Do you change the status here and raise the event after that?
//or
//Handler will cater all the process?

//Option 1
this.LicenseStatus = LicenseStatus.Approved;
//Do some other process the raise event

DomainEvents.Raise(msg);

//Option 2
DomainEvents.Raise(msg);
}
}

A Domain Service actually does the work, a Domain Event calls back to those who do the work.

Hope that helps.

What is the major different between DomainService and DomainEvent? After try your suggestion it seem that DomainEvent is similar to DomainService but instead of using normal call to object it will use event to call object and execute the method

Thanks

Thanks.

An entity/class doesn’t necessarily “own” the domain events it raises. Multiple entities can raise the same kind of event.

Between bounded contexts, I do use a kind of message/service bus, yes. One of the things we’ve been targeting with nServiceBus is a lighter-weight debugging model, but there’s still some way to go.

For a testing scenario, you could wire in your own handlers to do whatever you wanted, but I wouldn’t see that as a real context map.

Hope that answers your questions.

1. Does a class own the events it Raises or Can multiple classes call the same events;

2. With Bounded Contexts, do you always uses NService bus to communicate between bouded contexts, or do you ever do it in process in production or during a debug/testing phase. i.e would you ever see the case where a set of DomainEventHandlers became your context map between contexts (for a testing scenario) or say if the contexts were part of the same service?

Thanks,

Erik

My pleasure.
To your questions:

1. Domain events call synchronously back into registered code. If that code decides to fire and forget some messages elsewhere, that’s its choice. There could be two different handlers, one that does fire and forget, the other that calls back down into the same transaction.

2. The service layer’s responsibility is to handle the message that arrives while delegating business logic to the domain model.

The process that you describe is probably not what would necessarily happen – inventory can be handled by a separate transaction later. Discounts could also be handled by a separate bounded context, being consistent within a couple of seconds of the first.

These processes are usually handled by events between bounded contexts – not the service layer. There’s plenty of flexibility in that approach.

Hope that answers your questions.

Since you’d want all those activities to succeed or fail together, you’d want them all running in the same transaction, meaning that the service layer would still need to manage things.

Service layer just calling single Api domain model.
call shoppingcart.additem(product) which encapsulates above steps.

First process is more customizable/flexible for different scenarios. Different discounts but in a way business rules are implemented there.
Second hides everything away but loses flexiblity.

I did mean “that transactions should actually NOT be handled in domain objects”.

Hope that helps.

In your section on concurrency you let the consuming code decide that the purchase method of the customer model should be a transaction. Is this just an example on how to deal with concurrency or do you mean that transactions should actually NOT be handled in domain objects?

/Bjorn

Glad you liked it.

While the domain object *could* have an instance of the bus injected into it, that would break its encapsulation – requiring it to know about the message schema as well. Better for it to just say what happened – logically, and let something else handle the rest.

Does that answer your question?

I really enjoyed reading your article. I went back and read your post about domain events “Domain Events – Salvation Sunday, June 14th, 2009″. I am a bit confused on the relationship between domain events and service buses like NServiceBus. For example, the customer.DoSomething() method raises a domain event, could it not send a message with NServiceBus and do the same thing? How would you choose one implementation over the other?

It really depends on a lot of other detail that I wasn’t able to fit in to the article. For example, the shopping cart itself could have already taken into account all the discounts before the customer actually performs the purchase. That logic could also be put in a different bounded context.

That keeps any entity from getting too large.

Finer requirements around reports/queries usually deal with horizontal filtering – which rows is this specific user authorized to see.

That behavior really doesn’t belong on the entities themselves. A better place to put it would be as a set of filter objects which acts upon the rows before they are shown to the user. This is a good candidate for a pluggable design allowing multiple bounded contexts to contribute their own filters.

I hope you’ll forgive me not mentioning this important point.

customer.Purchase(shoppingCart);

Wouldn’t that line be better off on a domain service rather than the customer ? When purchasing you might check for some discounts that you can apply to the customer (with a list of discount levels coming from the db ) or some other stuff – would you still have the method on the customer ?

I’m thinking that having “customer.Purchase(shoppingCart)” will make the entity quite a large class after a while .