How to make use of DTO, domain model, value object,

Question

I am designing the different layers of a scheduler in c#. This is going to be a service running in the background without a GUI.

This is my baseline for the architecture (of course only being a small snippet of the structure.

![1] (https://i.stack.imgur.com/v34D6.png)

I am uncertain about "best-practice" in terms of architecture. I have been reading about, POCOs, Value Objects, DTOs, Domain Model and from what I can understand, the presented below is a wrong approach to DTOs.

In my class "ScheduleDTP", I have several methods doing some relatively complex manipulations with date coming from the database. CalculatePriority is a simplified example of one of the methods

Database properties:

ID, Name, Frequency, LastRun

Manipulated properties:

Priority

The purpose of the jobmanager is to evaluate all schedules and on-demands.

To my understanding the DTO should only contain the data, and transfer that between the different layers. I also believe that this should not be the JobManagers responsibility either.

public class ScheduleDTO
{
    public Guid ID { get; set; }
    public string Name { get; set; }
    public int Frequency { get; set; }
    public DateTime LastRun { get; set; }

    //Calculation based on the values above
    public double Priority
    {
        get
        {
            return CalculatePriority();
        }
    }

    public double CalculatePriority()
    {
        return (DateTime.Now - LastRun.AddSeconds(Frequency)).TotalSeconds / 100;
    }
}

Should I create some different type of object, POCO, Domail Model, ..., that manipulates the data in the DTOs?

I really appreciate any help about how to construct the different layers or something that that could lead me in the right direction

Answer 1

This is normally handled by a Service layer (aka business logic layer, BLL, etc). The service layer's job is to hold the core business logic. There exists a long-standing argument about whether this layer should be used, or if it should be integrated into the domain objects. See this post for more details and do some googling about anemic domain models and transaction scripts.

In general, when I see anything called "Manager", I immediately flag it for close inspection. It is likely violating rules around Single Responsibility Principal. It ends up creating "God Objects" which are usually a very dangerous anti-pattern.