ReHow to create fully encapsulated Domain Models
Those rules are, if I understand them correctly:
- Every message should resolve to a single method call on a domain object. The message handler is responsible for setting up the environment to call this method (getting the parameters, mostly).
- The domain model should not throw exceptions. This is mostly because attempting to handle exceptions often lead to handling too much or too little. It is easier to define all the domain operations as throwing no exceptions, in which case all exceptions are infrastructure exceptions (or bugs).
- Communication to the outside world is done using events. To decouple the domain from the service layer.
Things that I am not sure about:
- What are the roles of services using this model. As a simple example, when new user is created, we should send a welcome email. This involves technical services (IEmailSender, ITemplateEngine, etc) and probably a domain service as well (INotifications.SendWelcome) I am not sure where those fit in.
- Rules - Same thing. How do I handle things like executing a set of rules in a business action?
Anyway, I thought that it would be interesting to see how I would approach Udi's sample using my own style. What I ended up with is this:
public class AddGameToCartMessageHandler : BaseMessageHandler<AddGameToCartMessage>
this.tradesRepository = tradesRepository;
this.gamesRepository = gamesRepository;
public override void Handle(AddGameToCartMessage m)
Future<TradeInCart> cart = tradesRepository.GetFuture<TradeInCart>(m.CartId);
Future<TradeInCart> g = gamesRepository.GetFuture<Game>(m.GameId);
private void SetupErrorHandling()
Domain.FailureEvents.GameReportedLost = delegate
Domain.FailureEvents.CartIsFull = delegate
Domain.FailureEvents.MaxNumberOfSameGamePerCartReached = delegate
It doesn't look that different, but let us look at the details, shall we?
- We don't deal with the session. That is duplicate code that can get quite annoying.
- Transactions are implicit. This saves the whole (who forgot to call tx.Commit() ) again.
- The use of futures to get both cart and game at the cost of a single call to the DB.
- Moved error handling to a separate method.
- We do not use events, this saves us the trouble of having to unregister them (or manage them using weak references)
- What we can't see is that an attempt from the domain model to call a delegate that wasn't registered would raise an error. I don't believe in ignoring errors.
I am not sure what to do about the transaction when we run into a domain error. Should we assume that the domain is smart enough to revert state changes? I am pretty sure that this is not something that we would like to assume. But, does it make sense to rollback the transaction? An attempt to add a game that was report lost should probably trigger some alert somewhere, we don't want to roll that back, obviously.
More posts in "Re" series:
- (09 Jan 2018) Early bird pricing for RavenDB workshops about to close
- (24 Dec 2013) End of year 32% discount coupon is still valid
- (24 Apr 2013) RavenDB Webinar Tomorrow
- (07 Oct 2011) RavenDB and NHibernate courses–New York coming up
- (24 Aug 2011) Advanced NHibernate Course–Warsaw, October 2011
- (26 Jul 2011) RavenDB & NHibernate Training - August 15 - 16, Chattanooga, TN
- (12 Jan 2011) NHibernate Course in Dallas, March 2011
- (11 Feb 2010) Linq to SQL Profiler goes 1.0 on the 14th