It depends on the type of architecture you want.
- In Domain Driven Design, you would create a Domain Model that would have both data and functionality.
This would mean that an
Order has a property (or method) that would return the total price of the order based on the
Order would also have a method
AddOrderItem(Product product, int amount) and the
Order would check if there is already an
OrderLine for that specific product.
In such a model you would also have objects that are not real entities, like a
Repository for accessing data or a
Factory for creating entities. These are called Domain Services. An Application Layer is responsible for calling the Domain Services (for example to retrieve an entity from the database) and then it will execute functionality on the entity. The
Application Layer should be as thin as possible.
This is a nice article about DDD which explains these concepts in more detail.
- You can also use an Anemic Domain Model. That means that your entities consist of get/set properties and contain no behavior. In such a design, your Business Layer will contain the behavior, such as calculating the
Order price and checking for duplicate
There are different opinions whether an Anemic Domain Model is a bad thing. Personally I prefer a real Domain Model.
This article describes the differences between an Anemic and non-Anemic Domain Model.