MSDN Magazine Domain Model Article

Sunday, August 2nd, 2009.

My article on “employing the domain model pattern” has been published in the August edition of MSDN Magazine.

Here’s a short excerpt:

“In this article, we’ll go through the reasons to (and not to) employ the domain model pattern, the benefits it brings, as well as provide some practical tips on keeping the overall solution as simple as possible.”

If you liked this article, you might also like articles in these categories:

If you've got a minute, you might enjoy taking a look at some of my best articles.
I've gone through the hundreds of articles I've written over the past 6 years and put together a list of the best ones as ranked by my 5000+ readers.
You won't be disappointed.

If you'd like to get new articles sent to you when they're published, it's easy and free.
Subscribe right here.

Follow me on Twitter @UdiDahan.

Something on your mind? Got a question? I'd be thrilled to hear it.
Leave a comment below or email me, whatever works for you.

26 Comments

Victor Kornov Says:
August 2nd, 2009 at 5:34 pm
The MSDN article is an interesting read, as usual.
I was put off a bit by the comment “…If you don’t need the behavior found on those domain model classes, why plough through them to get at their data?..” This is totally reasonable when you really do not need domain behavior/rules in your reports (queries). But what if you do need them? I would like the article to at least mention those cases 😉 Otherwise it looks like you intentionally didn’t mention that to prove main point of the article. I mean things like exceptions vs. returns codes did get a least a short comment.

roxin Says:
August 2nd, 2009 at 8:35 pm
Hi,

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 .

udidahan Says:
August 2nd, 2009 at 10:25 pm
Victor,

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.

udidahan Says:
August 2nd, 2009 at 10:28 pm
Roxin,

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.

Joe Says:
August 3rd, 2009 at 6:54 am
Hi Udi,

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?

udidahan Says:
August 3rd, 2009 at 12:14 pm
Joe,

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?

Bjorn Says:
August 4th, 2009 at 4:37 am
Hi Udi and thanks for another great article.

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

udidahan Says:
August 4th, 2009 at 12:56 pm
Bjorn,

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

Hope that helps.

Bjorn Says:
August 5th, 2009 at 5:14 am
What about when you have vanilla DAOs below your repos instead of some OR mapper. Then a repository operation on an aggregate would likely involve hand-coded SQL-operations in the DAOs on more than one table. Is it still the service layer that should start the transaction or should it be done by the repository that encapsulates the DAOs?

AT Says:
August 5th, 2009 at 7:57 am
Hi Udi,
I really liked your article. Big thanks for sharing knowledge.
Couple of questions.
1. Are domain events are for fire and forget operations only or they participate in business transactions i.e.
2. What are resposiblities of service layer? If there is single api for domain process then there is little for service layer besides starting transaction. i.e. Adding item to shopping cart.
Service layer coordinating steps.
a. Check inventory
b. Check product discounts
c. Check special customer discounts (preferred custormer)
d. call shoppingcart.additem(product)

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.

udidahan Says:
August 5th, 2009 at 10:43 am
Bjorn,

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.

udidahan Says:
August 5th, 2009 at 10:55 am
AT,

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.

Erik Says:
August 5th, 2009 at 2:54 pm
Udi,
Good article. I have a couple of 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

udidahan Says:
August 6th, 2009 at 12:22 am
Erik,

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.

ryzam Says:
August 7th, 2009 at 8:18 pm
Hi Udi

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

udidahan Says:
August 8th, 2009 at 12:42 pm
Ryzam,

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

Hope that helps.

ryzam Says:
August 9th, 2009 at 6:50 pm
Thanks Udi,
I’m new to this approach, need times to really understand.I have another questions.

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);
}
}

udidahan Says:
August 11th, 2009 at 5:00 am
Ryzam,

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?

Jan Ove Olsen Says:
August 15th, 2009 at 4:22 pm
Hi Udi

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.

udidahan Says:
August 16th, 2009 at 4:26 am
Jan,

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

Szymon Kulec Says:
August 28th, 2009 at 12:47 am
Greetings Udi,

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?

udidahan Says:
August 29th, 2009 at 1:26 pm
Szymon,

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.

Mike Says:
December 2nd, 2009 at 7:33 am
Hi Udi,

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

udidahan Says:
December 5th, 2009 at 5:37 pm
Mike,

This would most likely be communicated via email.

Ranjan Says:
December 12th, 2013 at 3:38 pm
Hey Udi,

Really it is interesting article. Could you please update the code sample, so that we can download and execute on my end?

Thanks,
Ranjan

udidahan Says:
December 21st, 2013 at 12:17 pm
Hey Ranjan,

In all honesty, I’m probably not going to get around to it.

Sorry,

Udi

MSDN Magazine Domain Model Article

26 Comments

Your comment...