Organizing Logic

Martin Fowler has a recent entry about Anemic Domain Models as an antipattern. The gist of it is that a common [anti] pattern he sees is that application layer (or service layer) is very heavy with logic, whereas the domain model (the core business/data objects) is too thin, if not completely devoid of logic. Fowler claims that this turns development back into a procedural model, with the application layer providing all of the procedures that operate on the domain model data structures; and that this flies in the face of a founding tenet of object oriented development - namely, the joining together of data and process.

This is an issue I've been struggling with, and I have to say that I tend to prefer the service layer approach, at least in my current external data store based applications. Knowing what to put in the domain model, and ensuring it gets loaded up in the places it needs to get loaded, is a fair bit more difficult. Most applications and business processes revolve around more complex actions that deal with multiple objects, and exposing those interfaces as a service tends to be much easier to manage (situation depending). I agree that a domain model should not be completely devoid of process - but I'm finding most complex process code gravitates away from the model.

I'm finding this to be even more true when dealing with very central and complex business objects. In one case that I have, there are three different Table Gateways that map to a single table. They have different business responsibilities:

1. Create and Maintain all of the data in and associated with the particular table. There are complex business rules about dates, and there are special bits of data that are created at creation time that deal with how a particular set of users access the data in this table.
2. Updates on limited subset of the data in the table that doesn't need all of the complex business rules. This is usually for other modules and service layers that need to increment a count field or change a status field.
3. Public access (read only). This gateway has complex loading logic that is used heavily on the public side of the application, and extra fields are dynamically computed and added to the loaded data that the public face of the application needs.

The separation of services according to usage and access gives extra security and guards against accidental data corruption. Most situations aren't as complex as the one stated above, but the separation between maintenance/administrative services and gateways and public facing ones has been beneficial for one of the applications I'm working on now. It has also allowed the plumbing to change without impacting the public side design of the first version of the application too deeply.

Still, the "where does the domain logic go?" question plagues us. I have my data layer, which has not been extracted into a harvested framework yet; a coworker has been developing a much more detailed one with (with different requirements) based initially on my patterns but going towards different goals; and as we go into 2004 we hope to turn them both into a solid data access framework to develop and deliver applications on. The domain logic organization problem is significant. Actually, logic of any kind's organization is significant. Already, much of the data access logic is encoded in rule sets that can be combined in different ways off of a schema, and that alone is a significant piece of business logic. However, that does not encompass business processes. Placing an order, filing a maintenance report, managing email servers - all of these processes are services. They can be objects, in that they can be persistent and are often some sort of class instance (true in our case), but ratio of data to process is heavily skewed in the process direction.

Maybe I'm just thinking about it all wrong. In any case, as we start evaluating architecture, I'm hoping something solid will reveal itself for our situation(s). In the meantime, I'll probably continue to read articles and books championing the process heavy domain model and thin service layer approach, and ones championing the heavy service layer and thin domain model approach.