Don’t worry about the “as before” as the code was taken from an article in which it was developed bit by bit.

The DomainEvents class is infrastructure, below both the Serivce Layer and the Domain Model.

On the name IHandle, might I suggest maybe IHandleDomainEvents instead.

Thanks for your comments.

I read through the post and it describes Craig Larman’s view on *Problem Domain Object Models*, not the Domain Model software artifact I’m describing in this post – I’m afraid it’s a bit of an apples to oranges comparison.

I do think that more developers should know about the kind of modeling you describe in your post, though.

Thanks for the link.

– Udi

Your English is perfectly understandable – no worries

I did go through some posts on your blog – looks like good stuff. Welcome to the conversation.

I reviewed the post in my blog as the English was really bad. If you care to read it (or re-read it) Udi and pass on some comments would be really a learning experience.

It mainly addresses the Domain Model for the example you used but in a different and better way (at least IMHO).

What may interest you is that I may be wrong but my approach to the Domain Model and the way you propose Domain Errors to be reported back to the caller don’t mingle that well. At least I don’t see a recurring technique to apply them. Especially when Domain Objects call each other services to perform their activity.

That is why I don’t like how errors are reported.

Nuno
PS: Has you may have guessed already, English is not my mother language, so I’ll try to be carefull so that my impressions can get across without much effort.

> Consider a Web Application where this service is in assembly that is directely referenced.

It doesn’t work like that. The web app would send a message to a different process which would run the above service layer.

You can find out more about nServiceBus on the site http://www.NServiceBus.com. Take a look at the overview section.

Started commenting the ideas presented regarding modeling the domain, but it started to be too long. So I stopped, put together the ideas contrasting and complementing the one presented here on an article in my Blog.

Just started blogging my mind away last weekend so please fill free to point out some deadlocks of mine, I can only learn and share.

Here it is:

http://movablesharp.blogspot.com/

I like the nServiceBus idea (it seams that you are using it right?).

Consider a Web Application where this service is in assembly that is directely referenced.

Using that scheme, what would the caller of the AddGameToCartMessageHandler have to do to check for errors?

Do you have any framework that we can read to understand this? I mean
BaseMessageHandler, what is this? What does it do?

If it what I think it is I like in principle, but would like to see it further

Nuno

You can expose collections as IEnumerable so that there won’t be any Add/Remove methods available.

On your NHibernate specific question, you wouldn’t do anything different in the mapping to work with these interfaces. Just use Ayende’s repository wrapper around it.

By locking down the set’s to internal,private, or protected you can give NHibernate special set access via the proxy but keep the entities better encapsulated.

However, I have noticed that for collections, like Lists/Bags we may lock down the setter but leave the get public. The problem here is that I can then add/remove items directly from the collection and avoid any Add/Remove methods that employ business logic.

Do you have a recommended solution to avoiding this possibility? My guess is that you would make the mapping use field level access and avoid a Property altogether.

My next issue, is NHibernate specific, so I apologize if this is outside the scope. If the desired solution is field level access, how would this work if I define my class as an interface within the mapper with concrete classes defined as subclasses? Would I have to define that particular property on every subclass?

In CQS, you don’t query against the transactional data – so that wouldn’t really hold here.

I’d argue for a saga across aggregates.

Depends, if a behaviour crosses aggregates then I think its fine to ask each aggregate whether they want to proceed before starting. Plus if you don’t ask you can still tell them what to do and they will in turn tell you if they can’t fulfil their part (using an exception).

> Also, by and large you don’t have single methods updating across
> aggregates. The cases where I’ve seen that happen were where the
> domain model was too big, trying to capture rules across multiple
> contexts.

Not sure I agree with that, I’ve quite often seen multiple aggregates involved in a transaction. For example if you use party archetype then the party and its role or a relationship could all be involved. Guess it depends on how your domain model is designed though.

> My domain classes allow other layers to ask questions, so you can ask can I do this?

I’m afraid that that violates the “tell, don’t ask” principle of OO.

Also, by and large you don’t have single methods updating across aggregates. The cases where I’ve seen that happen were where the domain model was too big, trying to capture rules across multiple contexts.

About the CONSTANTS – you’d have to set up some kind of injection for your entities, currently not well supported by the ORM tools.

There’s a deeper issue here around who can change the behavior of the domain, and how, and who tests that the domain behaves correctly under the new config, and if this impacts data already saved in the database.

In short, there’s no silver bullet.

thanks in advance

1) Dependencies – Avoiding domain having external dependencies, this was what the original question was about in relation to rule 3. You’ve solved it by just having a collection on the entity, avoiding the need to go to the repository.
2) Handling any failures – Which is where events come in.

The two approaches can be used seperately and its the second one that I guess is more interesting…

“The only problem is that the Domain Model needs to know that the service layer had a default catch clause so that it wouldn’t blow up. Otherwise, the service layer (or WCF, or nServiceBus) may end up flagging that message as a poison message (Read more about poison messages). You’d also have to be extremely careful about in which environments you used your Domain Model – in other words, your reuse is shot.”

I see it a little differently. My domain classes allow other layers to ask questions, so you can ask can I do this? If the answer is no then you are given a nice Notification style object full of useful information explaining why the operation cannot be done. If however you ignore this nicety and try to proceed with the action anyway then we raise an exception (exceptions being useful when a method cannot do what it was designed to do).

Exceptions are thus very rare and generally indicate a programming bug, you forgot to check that the operaiton was possible.

As you say if the caller does not pay attention and we do throw an exception then it might cause a failure, but then the equivalent of not catching an exception is not attaching to the error event handler and is it really better for the system to continue on after that happens?

You can also solve the retry/multiple responses issues, I’ve definitely had exceptions that we caught and retried and bulked up errors into one exception and both worked well.

Despite using them my main problem with exceptions is that if you get all sorts of layers catching exceptions then it gets difficult to impose a policy that enforces consistent handling for particular types of exception. However this doesn’t invalidate the whole approach.

“In order to handle all aspects of the problem in as simple a way as possible, each part of the solution has to follow certain rules. By having the service layer only call one method on the domain model, transaction management, error handling, and correctness all “just work”.”

Let me check I understand. Lets say that within the single domain method we need to coordinate some work accross two aggregates, each is being updated. The update to the first fails and we raise the appropriate FailureEvent, the domain service/method has already subscribed to this event and its handler ensures we don’t continue with the update to the second aggregate. In addition the event is then also handled by the service layer. Does this sum up the approach?

You can see my solution here: http://morten.lyhr.dk/2008/09/how-to-create-fully-encapsulated-and.html

It would be nice if there was a library that wrapped this up, wouldn’t it?

I guess my question targeted your “show user message” comment, specifically the delegate part of it.

I’m afraid that on the issue of performance/distribution we’ll have to disagree – some things can’t be solved after the fact. Now, as a result of my consulting practice, I may tend to see a larger percentage than most where that occurs. The result is usually a redesign/rewrite.

Not that I’m against well designed, testable code mind you