Question

In one of my projects, I’m using an n-tier architecture

DAL (Repository Pattern) <-> BLL (POCO Services) <-> Web UI (ASP.NET MVC)

I created a generic repository and everything is fine on the DAL layer.

in the Business Logic Layer, I have my service methods which operates like (the example I love to use because of Pizza 🙂

myOven.Bake(myPizza);

even though, I need some specific information which are internal to the object myPizza, like this:

myPizza.GetBakeTime();

I know, I can use something like:

myOven.GetBakeTimeFor(myPizza);

which can calculate it, but I don’t want to put that specific logic into the myOven object (the service layer here), instead, I want to include that in myPizza, like

public partial class Pizza
{
    public double GetBakeTime()
    {
        // calculate Bake Time and return, based on other variables
    }
}

I mean, to extend my ORM-generated class and provide this functionality.

My question: I know, that this can be done theoretically but is there any considerations should I take into account when using both Domain Logic and Business Logic for the same class?

Answer 1

The Domain Layer should handle ONLY business related functionality. The Repository handles persistence of data. Those two have different purposes and should not be mixed together.

Also the Domain layer pretty much is the Business Layer. For this particular example, where you only want the baking time, then a specialized query repository should know the answer without involving the Domain (because it’s precomputed). If you want to know how much time is left for baking, then a Service (part of the Domain) can get the value using the Oven and Pizza entities.

However, this is already too specific and might not be suitable at all for the real problem you want to solve.