A while ago I posted about Fat Controllers. Another area that can quickly get beyond you are any domain level services that you have. Often this is exactly what your controllers are calling. Services should have no state and do co-ordination and control. Your domain logic should not live in the service layer, it lives in the entities that your service co-ordinates.
In a Domain Driven Design architecture your service often serves to retrieve aggegates from one or more repositories and then co-ordinate calling methods on the aggregate roots to carry out your intent.
One way to see that problems have arisen is if you have what Fowler calles the Inappropriate Intimacy smell between the service and the aggregate root.
Sometimes classes become far too intimate and spend too much time delving in each others’private parts. We may not be prudes when it comes to people, but we think our classes should follow strict, puritan rules.
A good aggregate is a boundary to outside interference, somewhat akin to a facade. If outsiders want something from within the aggregate then they are best of asking the root for it, not drilling into the graph of objects under the root. Watch for using the dot operator to navigate your way into the aggregate as a smell that your service has inappropriate intimacy. That inappropriate intimacy will almost certainly result in domain logic leeking out of the entity and into the service layer
The Inappropriate Intimacy smell is closely connected to the Law of Demeter. Simply put the Law of Demeter says that we can play with our friends but we shouldn’t touch their intimate parts. A more complex definition is that we should only call methods on objects that we own, create, or receive as a parameter, not on objects that are returned from one of those ‘friends’ by a method call or property access.
As an example the code below violates the Law of Demeter, because it chains through from our friend to one of its intimate parts
var options = product.Characteristics.SupportedOptions;
It’s likely that we are getting the supported options because we want to perform some business logic with them. It would be better to move the logic that needs those options down to the Characteristics or SupportedOptions level as appropriate.
Sometimes the Law of Demeter is treasted as though the code is more what you’d call guidelines but violation is usually a sign that you are bleeding domain logic through an open wound.
One area of temptation that seems to be catching some right now is the use of LINQ expressions. LINQ expressions can provide you withe a concise and declartive way to iterate over a sequence and perform operations, but they can be tempting to code so that they violate the Law of Demeter, just because you can, pulling domain logic into the wrong location. Consider the above example again:
var matchingOptions = from option in product.Characteristics.SupportedOptions
where option.Code == “Foo”
select new Match {Code = option.Code, Price = option.Price, InStock = option.InStock};
The solution here is to move this logic down on to iterate the list from within Characteristics and provide a method on Option that allows creation of a Match without exposing its details to the caller
If you don’t watch for inappropriate intimacy you will find that you end up with transcation scripts in your services. Those in turn lead to duplication, because it becomes hard to find existing funcionality that already provides that feature. Duplication makes our system difficult to maintain because we have multiple versions of the truth which increases the cost of updates and the risk that they disagree as to what the truth is.
