I'm trying to apply Clean Architecture to a simple ASP.NET MVC Core app by following Microsoft's ASP.NET architecture guidelines and their eShopOnWeb sample project.
In the standard Clean Architecture approach, business logic is put into "Use Case" classes in the core project. In the Microsoft's example, there are no Use Case classes, but it does have Services inside the Core project. Are the services inside the core supposed to be same as use cases? If no, what is their role?
In Microsoft's example, it uses "Services" as a group of Use Cases of the same Entity. Following the Clean Architecture approach, each use case should be a different class, implementing only one Execute method, which is the operation of the Use Case.
According to Ardanis (one of the main contributors of eShopOnWeb):
This would handle operations involving multiple aggregates or entities
This is what you see happens here. On BasketService.cs, you see more complex logic than you don't have in the IAggregateRoot
Services, or Application Service Layer is an application pattern defined in the book "Patterns of Enterprise Application Architecture" By M. Fowler. These service classes basically encapsulates a series of actions related to a given entity or business capability with the goal of extracting such logic from the UI/Presentation Layer (Typically from your controllers)
A service class might be the port to a series of use cases exposed as methods, or a single service can map to a single use case thus exposing only a method. There're variations of this though in form of mediator pattern; here the mapping of command - handler- use case is typically straight forward.
Keep in mind that services have to be relatively thin: they should only orchestate calls to different IO adapters, such as the database or the message brokers and delegate the business decisions through calls to the domain objects.
What is the difference between Use Cases and Core Services?
In this context: the name.
Sure there are a few different ideas here but there are far more names.
In the Microsoft's example, there are no Use Case classes
Really? Lets take a look:
- BasketService.cs
- OrderService.cs
- UriComposer.cs
Using a shopping basket seems fairly use casey to me. As does placing orders. Uri composing seems a little iffy but I wouldn't kick you out of a design review over it.
Understand, the objects themselves aren't use cases. They are objects that are beholden to the use case. Which is an entire story of a user using the application, in a particular case. Not an object. I've talked about this before. Uncle Bob has never said these objects are what use cases are. It's simply one (of many) names he sometimes uses for this layer.
Calling them "core services" doesn't really change what they are for. It changes who it seems like you're emulating as you put together the design. It makes me think the designer is following Jeffrey Palermo's Onion Architecture. To his credit, Uncle Bob outright admits he was following him too.
These superficial differences are why I call these, as well as hexagonal architecture, the buzzword architectures. The different names for the same ideas seem to be designed to drive you to particular blogs and books.
That isn't to say the ideas are bad. Just that there's a layer of hype to peel back to get to them. Once you do that, it can be nice to get the different perspectives. but it can cause a fair bit of confusion on the way there.
Of all the names to use for this stuff service is fairly neutral. It just means something that gets used. So don't assume just because the names don't end in UC that the same idea isn't alive in here.
