What logic should domain contain? about northwindtraders HOT 2 CLOSED

My understanding from a lot of other guides (and including this repo as a driving source for my own implementation) is that the business / domain logic should be held within the domain (see the readme in domain project). At the time of writing this, business rules / domain logic hasn't been really implemented.

The only example that I have found so far is within ChangeEmployeeReportToCommandHandler which restricts an employee from reporting to themselves. For this example, you could handle it within an AbstractValidator as such:

public class ChangeEmployeeReportToCommandValidator : AbstractValidator<ChangeEmployeeReportToCommand>
{
  public ChangeEmployeeReportToCommandValidator()
  {
    RuleFor(x => x.ManagerId).NotEqual(x => x.EmployeeId);
  }
}

Or you could implement it within the Employee entity in the domain:

public class Employee
{
  // Properties...
  public int ManagerId { get; private set; } // Notice private setter

  public Employee Manager { get; private set; } // Notice private setter

  public void ChangeManager(Employee manager)
  {
    if (EmployeeId == manager.EmployeeId) throw new Exception("An employee cannot manage themselves");

    Manager = manager;
  }
  
  public SomeValidationResult Validate()
  {
    if (ManagerId == EmployeeId) // Add a validation error
    return // validation error(s);
  }
}

You could also change ChangeManager to not throw exceptions and return some sort of validation results instead.

Example 1 has the advantage of preventing a database call and the disadvantage having to repeat yourself if you need to prevent this in some other implementation (updating an employee a different way = a different AbstractValidator with the same rule). This shouldn't really be treated as business logic and instead a "time saver."

Example 2 has the disadvantage of a database call for existing entities but the advantage that no one can change managers without going through ChangeManager where the logic is held.

I am striving for a mixture of 1 and 2 with heavy emphasis on 2. You can use the first to prevent database calls if that is a major concern for you or ignore it entirely and just focus on the second to prevent repeating yourself.

That's my $0.02 from a desktop implementation and not a web implementation.

from northwindtraders.

Hi Jason. Thank you very much for your sample. I like it very much!

You're welcome, sorry for the delay getting back to you.

I want to ask you about domain logic. What kind of logic should this layer contain?
Could it contain some business logic, e.g.?
Could you provide some clarifications, please.

Recommend to start by just adding logic to query and command handlers. When you find the need to duplicate logic, then push it out of the handler and down to the domain.

Thanks again and happy coding!

from northwindtraders.