Comments on: Injecting services into entities

By: Anonymous

Anonymous — Sat, 16 Jun 2012 18:08:00 +0000

Have to agree with Michael Annucci – there seem to be lots of opinions out there, but not much consensus on best practice or analysis from the DDD experts of the pros and cons of each approach. Here’s Dan Haywood, a very capable guy, suggesting some of the approaches you are against: http://danhaywood.com/2010/04/30/accessing-domain-services-from-entities/. I also have concerns that in data heavy applications (as most I work with in financial services are), the pure DDD approach (what I think you are encouraging here) either 1) results in anemic domain entities (where the majority of meaningful processing is done in a domain service layer) or 2) fails to make the best use of the more efficient database processing.

By: Anonymous

Anonymous — Thu, 01 Sep 2011 18:25:00 +0000

Don’t assume that DTOs mean that your domain model is anemic. Imagine if your DTOs were actually command messages, and your domain model accepted command messages in a method.

By: Michael Annucci

Michael Annucci — Thu, 01 Sep 2011 16:11:00 +0000

The frustrating part for me is that there is a dearth of good information on this topic that yields truly best practices. Everything that you read (Martin Fowler et. al.) suggests that the anemic domain model is a code smell. Inevitably if you suggest using lightweight DTO data containers with a service layer you get called some sort of anti-pattern procedural programmer. Yet, the reality is that for most MVC based forms over data applications you will end up with an anemic model using service layers for behavior if you want an easily testable and maintainable application.

As example let’s talk about the Customer.Orders situation from the comments below. It isn’t about weather Orders is a root or about lazy loading from O/RM. I am more interested in the best methodology for creating testable, loosely coupled rich domain models. I only see examples for the most trivial of cases with no real complex dependencies. In reality an application that has a create new Order behavior is much more complicated that merely persisting raw data into the DB. Initially it seems obvious to place the NewOrder() method as part of the Order domain object.

Very quickly you will run into dependency issues were those dependancies are needed only for this method and will tightly couple the order to many other services/objects. Something as simple as calculating the order total comes to mind. You will need to access the Customer.Billing address in order to determine state and local taxes. You will have multiple repository hits to get current tax rates. Another hit to the Order.Products.Materials collection will be necessary since some Bill of Materials are tax exempt. Then there is a call to the business rules service to validate that some order items either require or disqualify other line items. Another call to Inventory to calculate shipping items on hand (and shipping time). Another call to Shipping service with Customer.ShippingAddress to figure out estimated shipping costs. When that is all done the Order.Salesperson and Customer need to get notified by email through yet another application service.

I could go on but I hope you all get the point. This quickly becomes a strongly coupled untestable system just to adhere to the rich domain model. This could all easily be resolved by creating an IOrderProcessingService whose single responsibility is to coordinate the above workflow. Since all of those dependencies are required for the service you can use constructor injection or your favorite DI container to initialize the service rather than jamming them into a rich Order object as nullable properties. Simple, testable, maintainable but not “correct”? I must be missing something here.

By: bogardj

bogardj — Fri, 11 Feb 2011 13:21:52 +0000

@RichB

Still no need to:

public string GetCreditCardNumber(IDecryptor decryptor) {
}

If it’s an actual persisted value then yeah, IUserType would work. I’d probably go that route myself.

By: RichB

RichB — Fri, 11 Feb 2011 10:47:00 +0000

Additionally, as an “encrypted credit card number” is a different “type” than something which is not encrypted, perhaps using an IUserType and then injecting the encryption key into this IUserType is a better way to model it?

By: RichB

RichB — Fri, 11 Feb 2011 10:29:40 +0000

Let’s say you have a database which stores encrypted credit card numbers.

Obviously, the encryption key is held securely outside of the database. And it would make sense for a domain entity to be responsible for transparently encrypting/decrypting the credit card number.

Would you inject the encryption key into this domain entity?

By: ulu

ulu — Tue, 27 Apr 2010 19:56:02 +0000

I think we already can have a lazy customer.Orders property without injecting a service. NHibernate or whatever ORM handles that for us. From this, customer.OpenOrders is just a simple LINQ query. In your tests, the entity will not query the database, even though you don’t mock any services. In production, you’ll have a proxy object with the required service auto-injected for you.

By: isaiah

isaiah — Thu, 15 Apr 2010 13:13:57 +0000

Well it all really depends on the context, it may well be that customers has orders within its aggregate. But in that case Orders shouldnt have a repository of it own. In my experience Orders would be its own aggregate root, Orders have their own identity, not reliant on identiy o the customer,, a Customer could potentially have thousands of orders, its doenst fit well for customer to be managing all this. again all this depends on the context of your domain. anyways again the main thing from a DDD point of view is if it makes sense in your domain for orders to be part of the customer aggregate then Orders should’nt be retrieved from a repository, , it should be in the Customer, whether its lazy loaded or not is an implementation detail.
“The domain model says Customer have Orders…” do you mean the domain experts say that ?

By: Andy Hitchman

Andy Hitchman — Thu, 15 Apr 2010 11:31:47 +0000

@isaiah

So, if my Customer can’t contain a set of Orders (another aggregate), where does the responsibility for getting orders for a customer lie? Are you suggesting I need a service that takes a customer object or a specification for a customer and return a set of orders?

Isn’t having the ‘GetOrders’ method on the Customer object preferable in terms of discoverability for maintenance in the future?

The domain model says Customer have Orders, rather than needing to know that a service (/repository) can get Orders for Customers. (The GetOrders method is implemented to use this service internally)

By: isaiah

isaiah — Thu, 15 Apr 2010 09:58:02 +0000

@andy
In my experience having to pass a domain service such as a repository into an enity, is usually a hint something I need to rethink my design choices. In general an aggregate root should not have non-transient references to other aggregate roots. In your example Order seems like an aggregate root and doesnt seem right for customer to be holding references on to this.
More over lifecycle of entities and services are completety different. . One of key benefits of tests is the feedback they provide and help guide your design, i’m not a fan of tools like auto-mocking container and among others, they silence the feedback from test and simple hide underlying design issues