Service Layer

[mweel1]

Does anyone else seem like a service layer is missing in application when your trying not to repeat yourself (DRY)?

I have typically put my logic in the commands until I need to reuse them in other areas. I then move them to a service class.

Was wondering how other people are handling this, I cant be the only one.

Thanks!

[karimkod]

When you think about it, it's better to have separate logic for every Command/Query, since when you change you are going to touch one use case at a time, unless you modify the domain layer. However, sometimes, you find yourself doing the same thing in different places, ask yourself if it's really an Application layer logic (maybe it should be in the domain layer as a method of a rich entity). And AFAIK, there is no restriction rule about creating other classes that you can use in your application layer to abstract common logic.

[mweel1]

I've always had a conflict between putting business logic in my domain entities vs. a service layer. I kind of like creating services, this way my entities can stay enaminic and pure. Decisions, decisions. Thanks for the reply!

[CraigComeOnThisNameCantBeTaken]

I've always had a conflict between putting business logic in my domain entities vs. a service layer. I kind of like creating services, this way my entities can stay enaminic and pure. Decisions, decisions. Thanks for the reply!

1. I think you are confused about application layer code. The point is it represents a use case so code that looks the same is not necessary the same. They just happen to be the same lines at that point in time, subject to change anytime.

2. Talking about wanting anaemic domain entities in a clean architecture template project... I think you're trolling? Sorry if not.

[mweel1]

I guess I am confused. So if I have a domain entity. Your suggesting the process would look like this for my "business logic"?

var order = _context.Order.Where(w=>w.id==id).FirstOrDefault();

order.shippingDate = DateTime.UtcNow();
order.ShipOrder();

_context.SaveChanges();

The issue I have with this approach is what happens when ship order needs to operate on other domain objects?

What if I have infrastructure that needs to be called? Inject it into a domain entity?

What about serialization I can serialize a pure object much easier, and get it to a end point and then use services in a different context boundary.

[CraigComeOnThisNameCantBeTaken]

My answer might conflict with some aspects of this template as I am not an expert on this code base and I know it isnt traditional clean architecture.

The point of clean architecture (which I think is the same as onion architecture but thats just me) is to separate your code into 3 main areas:

domain - the area that represents why your software exists. The fact we have a database is not why the software exists, in fact a lot of the code we have to write is just a means to support our domain. If we ask a subject matter expert what the software should do eg asking HR Manager what they want Employee Management Software to do, they wont answer in terms of storing something in an sql database, taking it out, transferring it over http, showing it in a table using MVC. This might seem a pointless thing to bring up, but all that stuff is not why the software exists, and it certainly isnt language a HR manager would understand.

So we take the stuff that is truly about why we are even working on the project to begin with, our domain logic (What we think of as employees and contracts etc) and we put it in the domain layer hopefully using the same language that the HR manager would use. Why not eh? After all this layer is about the business and people using it so our code should be just as close to that.

In order to keep this later entirely focused on the greater reasons the software exists we use plain common objects with no injection of infrastructure stuff like entity framework. That will only distract from our pure representation of the enterprise / domain logic.

Application - The use cases. So we know an employee has a contract, and the employee cant be deleted if the contract is still valid - thats defined in the domain because its fundamental to the problems we are trying to solve. But the domain code can be reused for different user journeys - HR Manager deleting an employee from the system vs more complex logic checking if an employee has an expired contract or not to determine if salary should be paid. Both those use cases will no doubt involve checking if the employee has valid employment by perhaps calling employee.HasValidContract(). There may be overlapping lines in both cases but since this represents the business layer, and not our fundamental understanding of what an employee is, rather what we want to do with them, it is subject to change at any time if the business needs to change their operations. This difference between application and domain (use case vs fundamental concept of employees) is why it plays counter with DRY and I would argue application layer commands are all their own distinct operations with completely different reasons for change, and therefore even if they look the same, they are not the same and should not share code (or mistakes will be made in a team setting).

Infrastructure - Well we said domain wants to be pure so it wouldnt know about infrastructure. I think the application layer would know that infrastructure exists because saving something to a database is part of an operation. But application still shouldnt know much about the inner workings of infrastructure or it becomes tightly coupled. After all the use case for issuing bonuses wants to focus on that use case, not the fact we are using an sql server. If we start mixing the two then the code gets polluted with multiple concepts and whilst that doesnt really matter for 1 operation or a super small app, if its enterprise scale with a whole team of devs making changes it will turn to spaghetti.

So if the application layer needs its reference but not implementation I would argue for concrete repository interfaces defined in the application later and implemented in the infrastructure layer. But I know the author of this template deviated from that and went with just exposing EF. I disagree because I dont want to pollute my use cases with query generation and for testing reasons, but to each their own.

If you followed that then for me the code you wrote would look like this (with minor changes if you re going to use EF directly):

ctor(IOrderRepository repo) {
    this.repo = repo;
 }

public void ClientCode(int id) {
   var order = repo.Get(id);
   order.Ship(); // this should set the shipping date because thats fundamental logic of shipping an order. if you set it outside then we have a leaky layer and domain is no longer responsible for fundamental logic

   repo.Update(order);
}

[karimkod]

I let you read this good explanation why we use rich entities : https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-domain-model#rich-domain-model-versus-anemic-domain-model

In a nutshell, using anaemic entities is a procedural pattern and can easily lead to spaghetti code. However, in simple Crud applications you don't really need them you might even not need Clean Architecture for that.

[mweel1]

2. Talking about wanting anemic domain entities in a clean architecture template project... I think you're trolling? Sorry if not.

Not trolling, I am just trying to figure out where I put business logic that needs to be reused in my commands.

[CraigComeOnThisNameCantBeTaken]

The issue I have with this approach is what happens when ship order needs to operate on other domain objects?

What if I have infrastructure that needs to be called? Inject it into a domain entity?

What about serialization I can serialize a pure object much easier, and get it to a end point and then use services in a different context boundary.

If they are invariants to the order which is an aggregate root - its fine. If not you create a domain service to enable you to interact with two aggregate roots at the same time whilst still maintaining your fundamental concepts. Choosing aggregate roots and invariants is not always easy but is done not on references between two objects, but enterprise logic between the two that must be kept consistent such as validation

As in my other reply, domain shouldnt have infrastructure

I think again you are misunderstanding clean architecture. It has layers and the UI/API layer is fundamentally different to the domain layer and has different reasons for changing. You should map your domain object to a data transfer object, restful resource, etc.