Thick models Vs. Business Logic, Where do you draw the distinction?

Question

Today I got into a heated debate with another developer at my organization about where and how to add methods to database mapped classes. We use sqlalchemy, and a major part of the existing code base in our database models is little more than a bag of mapped properties with a class name, a nearly mechanical translation from database tables to python objects.

In the argument, my position was that that the primary value of using an ORM was that you can attach low level behaviors and algorithms to the mapped classes. Models are classes first, and secondarily persistent (they could be persistent using xml in a filesystem, you don't need to care). His view was that any behavior at all is "business logic", and necessarily belongs anywhere but in the persistent model, which are to be used for database persistence only.

I certainly do think that there is a distinction between what is business logic, and should be separated, since it has some isolation from the lower level of how that gets implemented, and domain logic, which I believe is the abstraction provided by the model classes argued about in the previous paragraph, but I'm having a hard time putting my finger on what that is. I have a better sense of what might be the API (which, in our case, is HTTP "ReSTful"), in that users invoke the API with what they want to do, distinct from what they are allowed to do, and how it gets done.

---

tl;dr: What kinds of things can or should go in a method in a mapped class when using an ORM, and what should be left out, to live in another layer of abstraction?

Answer 1

I'm mostly with you; your colleague seems to be arguing either for the anemic domain model antipattern or for duplicating the model in a "persistence model" with no obvious benefit (I'm working on a Java project where this was done, and it's a massive maintainability headache, as it means three times the work whenever anything changes in the model).

What kinds of things can or should go in a method in a mapped class when using an ORM, and what should be left out, to live in another layer of abstraction?

Rule of thumb: the class should contain logic that describes basic facts about the data which are true under all circumstances. Logic that is specific to a use case should be somewhere else. An example is validation, there's an interesting article from Martin Fowler where he makes the point that it should be considered context-dependant.

Answer 2

This is a judgement call that really depends your anticipated size and scale of what you are developing. The most rigid approach is to limit the ORM types to a data access component and use POCOs in a common library as types referenced and used by all layers. This would allow for future physical separation as well as logical separation. You could also decide that an additional layer should exist between the UI and the business logic layer. This is usually called a Facade or Business Interface layer. This additional layer is where your "use-case code" lives. The individual loosely coupled code is called by the Facade/BI layer (e.g. Facade has a ProcessOrder() function which calls into the business logic 1:M times to perform all of the steps necessary to actually process the order).

However, all of that being said: many times this amount of architecting is simply unnecessary overkill. For example, code specifically for a simple Web site where you have no intention of packaging its components for re-use. It is perfectly valid to create an MVC Web site and use EF objects for this type of solution. If the site needs to scale out later, you can look into clustering or a process often lost fray called "refactoring."

Answer 3

Just remind your colleague that you don't need to overarchitect the models as if this was a Java project. I mean, comparing two persisted objects is behavior, but it's none specified by the persistence layer. So the 6 beer question is: why have completely unrelated classes describing something about the same thing? Sure, persistance is a big aspect enough of a model to be treated separately, but not enough to warrant for it to be treated distinct of everything else. If you drive your car, wash it or bust it, your manipulating your car the whole time.

So why not just compose all these different aspects into a single model class? You need a bunch of class methods dealing with persisted objects--put them in one class; you have a bunch of instance methods dealing with validation--put them in another one. Finally, mix the two in and voila! You got yourself a smart, self-aware and fully contained model representation right there.

Answer 4

In addition to other answers, pay attention to hidden cavehats when using rich domain models with an ORM.

I had issues injecting polymorphic services in the persisted model classes when trying to achieve something like the following pseudocode:

Person john = new Person('John Doe')
Organisation company = organisation_repository.find('some id')
Employee our_collegue_john = company.hire(john)

In this case, an Organisation may require a HRService as a constructor dependency (for instance). You usually can't easily control the instanciation of your model classes when using an ORM.

I was using Doctrine ORM and the service container from Symfony. I had to monkeypatch the ORM in a not-so-elegant fashion and had no choice but to separate persistence and business models. I haven't tried yet with sqlachemy, thought. Python might prove more flexible than PHP for this stuff.