Using Services instead of MediatR?

[Audhut]

Hi All,
Currently I am in a process of using the CLEAN architecture for one of my projects and I am planning to use this template as a base for my code.
Instead of using the MediatR pattern I intend to use simple Service. This service will do exactly the same thing that the command handlers do. For e.g I can have a ToDo List service

public interface IToDoListService
{
    Task<int> CreateTodoList(string? title);

    Task DeleteTodoList(int id);

    Task PurgeTodoLists();

    Task UpdateTodoList(int id, string? title);
}

public class ToDoListService: IToDoListService
{
    public Task<int> CreateTodoList(string? title)
    {
       //some implementation
    }

    public Task DeleteTodoList(int id)
    {
            //some implementation
    }

    public Task PurgeTodoLists()
    {
         //some implementation
    }

    public Task UpdateTodoList(int id, string? title)
    {
           //some implementation
    }
}

In the service I also plan to do some validation and other processing apart from saving. ALso these methods will contain the bussies logic as well.
My question is. Where will the IToDoListService and ToDoListService reside? My feeling is it should be in the application layer.

Let me know your thoughts on this. Or correct me if I am doing anything invalid with this approach

[royberris]

Hi, while I would really advice CQRS over the service pattern you are correct. These services should reside in the application layer, they are application logic. It's important to know the difference between application and domain logic. The service pattern is popular in N-tier applications, which is where I guess you are coming from.
The application layer could both be a service pattern or you can use command or queries. In N-tier application we could also use CQRS instead of services. This doesn't directly have to do with CLEAN architecture.

Most important thing to take away from this, if you are new, is that with this template it is adviced to decouple logic and group it by feature. This means we do not group by type.

In most N-tier applications it's common to put all the models together in a folder, to put all the services together in a folder and to put all the interfaces together in a folder. This makes it hard to distinguish between logic, and this will guarantee 'contamination' at some point. Where you are reusing models for things they were not build for, or worse, doing service -> service calls.

The way features are set up is simple. You group by feature, like "CreateTodoListItem" and you place everything here, the request/response models, the command, the handler and the validator. This forces separation of concerns. With CQRS it is "forbidden" to initiate commands or queries from another command or query. There are cases for this but it is in general a bad practise.

It's up to you which you choose but choose wisely, you will take away a lot of the power this template provide when going with services.

To take the most out of this CLEAN template I would really advice to use CQRS because of the several benefits it provides. Honestly I'm not sure CLEAN architecture is the right architecture without CQRS, but this is my top of the mind opinion which I might strikethrough later when actually thought through.

I am not affiliated with this blog post but I recommend you read it through to understand CQRS better: https://softwarehut.com/blog/tech/Mediatr-library-for-ASP-NET