25

Recently I was faced a question about whether a simple calculation should be put in the Entity layer, or should the Entity be pure for just storing the raw data and leave the calculation logics in the business layer.

So my question is whether it is sensible to encapsulate simple calculations in the properties in an entity class?

2 Answers 2

29

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 OrderLines. 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 OrderLines.

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.

5
  • Hi Wouter, thanks for the answer and the links. I seem to face a wrong mind set that when used the Anemic domain model, all the business logics(even the very simple ones) should be put in the business layer. This seems non-sense in some cases where the business logics are really just depending on the model itself. For example, a property is calculated from the existing properties in the model. I couldn't find a sensible reason for putting the business logics that all depends on the model itself into the business layer.
    – Katat
    Jan 10, 2012 at 3:12
  • In an anemic domain model, as we have business classes as well as entity classes, how to name classes properly to avoid being confused between them? Do you suggest using suffixes? If yes, could you give an example?
    – Kwadz
    Feb 3, 2017 at 4:51
  • For DDD, what if price calculation logic is complicated? For example, the price is based on location (tax), user info (birthdate discount, membership discount), coupon, credit card (credit card special discount) etc. How can we put such logic inside Order class?
    – Sher10ck
    Jun 29, 2018 at 17:21
  • 1
    Your order aggregate should contain all these information needed to make the calculation. Because based on your description this should be actually part of the aggregate. But if the logic gets really complex and you might need to change it, then I would pass the calculator as an object to the entity constructor and let the entity use the calculator internally to set the price.
    – floriank
    Nov 29, 2018 at 15:25
  • Anaemic... the poor domain sounds as if it's suffering from some sort of illness. Wouldn't you rather be Driven?! Yeah! Jan 27, 2019 at 11:32
1

Well, Entity and business Objects are almost same, most of the time. For example if you have a product class and you want to expose a property which takes some existing property in product class and does some calculation and then exposes it. Its fine in the term that, the logic of creating that property remains with the class.

Now, the question may come, where to fit your business layer class. I prefer using business layer class which has some logic to deal with business problem. For example in your Product example, a business problem could be charging money using third party vendor like paypal.

One key thing to remember is an Entity would always have an identity but a business object are entity with out an identification. For example product is an entity but money would not have an identity. 1000 different instances of money would be same.

1
  • Yes. If the property's business logic all depends on the existing properties on the same model, it would be better to just add the property in the model. This would help loose the unnecessary couple with the business layer for the calculated properties.
    – Katat
    Jan 10, 2012 at 3:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.