Well lately i’ve been taking some .NET training courses, and my instructor at the class told me that in .NET MVC 5(or earlier versions) the models should not contain any logic. At first I thought he meant the models should not contain data access logic(aka no active record), which makes sense with well established data access layer/mapper. However, what surprised me was that he stated that the model should not even contain business rule/logic either, and these will be placed in service layer or application layer. And this was how most .NET project did with entity framework, the models would only contain data.
I was confused though, I learned by the very first day of my domain model design that the models should be fat and controllers should be thin, which implies the usage of rich model design. Stripping any business logic from the entities will make them anemic, and anemic domain model is an anti-pattern as described by Martin Fowler. I wont blame my instructor since he worked with many companies and all have been using anemic domain model design pattern. He was not the project leader, so he was just following his teams decisions. But I wonder, why is anemic domain model popularly used in .NET projects? Shouldnt they be moving business logic back to the model/entity, as anemic domain model is bad and rich domain model is good? Can anyone explain this phenomenon?
From what you’ve written, it sounds like you’re conflating entities (data models) and domain models (actually a layer, rather than an object). Some seem to take the statement ‘Fat model, thin controller’ to mean stuffing all your domain logic into entities, which then end up violating the Single Responsibility Principle. Encapsulating logic in domain services keeps it in the model layer where it belongs, without creating bloated entities that do too much.
Oh really? Thats very interesting, but by what I heard from Jeff Mott, an entity is a domain model. Entity is just the term for domain model used in DDD, and the two words are interchangeable:
If you look back to that linked thread, we also continued to talk about things like value objects, which are also part of the domain layer and contain business logic. I guess the whole thing hinges on how you define the term entity - I tend to use the definition that it’s an object with an identity that is independent of it’s properties, but perhaps that’s more a DDD point of view… some might use entity just to describe anything that exists as a separate concept within the domain model… value objects would certainly come under that description.
Imagine you’re modelling some sort of payment system where customers are eligible for discount according to certain rules (e.g. when purchasing x number of products from y category). These rules would certainly classify as business logic, which belongs in the domain model, but would you call these rule objects entities?