How much logic should be in your domain model objects

Question

Just finished read this post by Greg Young, where he is talking about Microsoft recommending patterns with dumb data transfer objects. He implied that in the Java community, things are trending the other direction.

My question is how much logic should be in your entity objects? Our philosophy where I work (C# shop) is that if you can't serialize it, don't put it in the entity.

Answer 1

Matt,

I would say that your shop is writing procedural code. I want to make clear that there is nothing wrong with that many large systems (including many I have worked on) have been written using procedural code. There is a time and place for it.

Now procedural code has no place in a domain model. If you want to use a more procedural style that is fine but use it with something like a Table Module or an Active Record pattern. It is not the lack of OO that I am considering to be so destructive in the guidance but the use of a domain model with procedural logic.

This causes one to spend a large amount of resources building the domain layer (impedance mismatch, thought process time to build aggregates, isolation, ubiquitous language etc) without receiving any of the benefits that the domain layer (generally maintainability) would otherwise provide. In other words while you may meet your functional requirements just fine you end up spending a large amount of your budget with almost no return.

Now to come back to what "is behavior" I would like to focus on the question from an Object Oriented as opposed to a "Domain Driven Design" viewpoint. An object will generally encapsulate some state and will generally expose some behaviors.

quick reiteration: encapsulate state, expose behavior

So what behaviors should an object have? Put simply it should be the behaviors that operate upon the state it is encapsulating. In an ideal behavioral OO world the state would never be exposed from the object only behaviors. Put tactically into code if we start seeing code like:

Customer c = GetCustomerFromRepository();
c.Status = CustomerStatuses.Deleted;
c.LastUpdated = DateTime.Now;
c.UpdatedBy = GetCurrentUser();
CustomerRepository.Save(c);

We have a SRP violation ... This code is code that should be a behavior of the customer object because the "Responsibility" of the customer object is to.

Encapsulate state about a customer and expose behaviors.

As such we can see that we would be better off having a Customer.Delete() method. (yes this is a bad example I know ...)

Now we would also get to this by using TDD. It is much easier for us to deal in tests with the seam that the behavior provides than the seams where all of the state is exposed. The reason for this is that I don't need to duplicate the logic in my tests. The client code doesn't care how a delete works ... it only cares that the customer exposes the behavior. As such in our tests instead of asserting that c.State == CustomerStates.Deleted and c.UpdatedBy==GetCurrentUser() etc etc we would simply assert that the delete method was called on the customer seam by using a mock.

Now to come back to the title. The amount of logic that should be in a business object is the amount of logic that falls under its responsibility of encapsulating its state. Sometimes this is alot, sometimes its not. There are places where you want to use services as well ... a good example would be coordinating the interaction between many domain objects for a given behavior but even here the service should be calling behaviors on the domain objects.

Does this help to clarify things a bit?

Greg

Answer 2

If you're calling them your "domain model objects" then I will assume that you're refering to Fowler's Domain Model pattern. http://martinfowler.com/eaaCatalog/domainModel.html

Given that assumption, then the answer to your question is "all the business logic" since that is essentially the definition of the pattern.

Unfortunately the term "domain model" seems to have been watered down recently to only mean an object model of your data with no behaviour.

If you haven't already done so, I would encourage you to read PoEAA and decide where you think that domain logic belongs in your situation. If you decide on a domain model, then I would encourage you to read Evan's DDD book and learn about the differences between entities, value objects and services.

Hope that helps!