I just want to add that I'm not re-inventing the wheel here. There were several other more notable people that talked about this issue, including Jimmy Bogard. In this video I just shared my experience where me and the teams I was working it managed to make some apps more maintainable which resulted in some very happy customers.
That's great, I was expecting at the end the same logic written in separated handlers, but the explanation as it is for me is now clear by what I have learned from your videos.
I have plenty of videos in the software architecture playlist where I implement handlers as well as in the livestreams where we buit the CwkSocial API.
Thank you for the video. I largely agree with the design of handlers and use them myself. However, this is like one of those discussions like "don't use repositories / always use repositories" where context matters. Using your example where there is a payment service and a finance service, there is also some logic encapsulated in customer service somewhere. Refactoring these to use handlers does not escape the problem that your payments handler and your finance handler at some point will require to fetch a customer, logic that already exists in the customer service. What options (rather than copying and pasting code from the customer service) do you have if you will not create some sort of customer service that will be injected into both the customer handler, the finance handler and the payments handler?
I agree here that not all problems are solved. @Codewrinkles I still can't use this approach with handlers because I can't understand and nobody explains how to avoid code duplication. If I need to get a product by id with EF, should I just copy code from another handler? I think we must have some wrappers, because later we introduce soft delete and we should fetch by id and not deleted. That problem can be solved with an extensions for DB Context. But we should always remember that they should be highly reusable with minimal dependencies. What do you think about the idea to create service and repository per feature? In scope of VSA we can have service and repository dedicated to specific feature and cannot be used in other features. In this case we still can keep clean boundaries like with handlers and share code with a DB Context extensions. But the benefits are: - service/repository approach is well known and easy to follow; - no need to create tons of classes like request/handlers; - easy to debug; - can be used with Clean/Onion architecture. Really looking for your answer.
Some code might have helped to understand why a handler is better and how does it fixes the problem. A handler is still a "service", more like a dedicated one. Does it matter if you call it handler or service? I don't think the mess you described is because you used a "service", it's because that service is bad designed.
Services will always end up being bad designed because of the DRY obsession. It's not a matter of "if" but a matter of "when" this start happening. On the other hand, I agree with you. If you would have one and only one service method that is responsible to handle just one and only one application action, it would be the same. This, however, defeats the purpose of the main selling point of services, which is "code re-utilization".
@@Codewrinkles Yeah, sometimes some thing which looks 'new' to me is nothing but some old principle in the disguise of some fancy new word. I think handler is nothing but the SRP.
Thanks for the great material! I just wanted to clarify some things. In my mind the main question on this video could be trsnslated to: " Orchestration/Process msnagement or Choreography". This means that if you chooose the first, there is a specific central place to handle the flow of a specific request, in the second case there isn't and the changes in one context are propagated via events. The main advantage of the second approach seem to be the decoupling which provides the flexibility of adding new handlers to create new flows without having to make changes to a central place. One downside seems to be the absence of a centralised place to have the knowledge of the application flow.
There's literally ZERO mid-sized project I have worked on or refactored in which we need to orchestrate things in a such a complex way. Bare MediatR notifications give you everything you need. But if the app is very complex then we'd probably be in a place where we'd need to add some extra complexity and implement messaging patterns.
I don't think they have to be mutually exclusive, you can have handlers that consumes services, like for example to avoid calling a handler inside another handler, in that case to reuse the same logic U have to create a service that's gonna be called from multiple handlers. Thanks for ur content
In my opinion the example you have is not optimal. This setup will lead to the exact same problem with state mutation across boundaries. You should use notifications to notify anybody else in the app that something of interest might have happened. The only type of services I think it's ok to use in handlers are infrastructure type of services, like sending email, uploading files and so on.
Of there are different reasons for change, then there is no code duplication issue as the SRP is not violated. The "code duplication" obsession causes more problem than it solves in most of the cases. ruclips.net/video/v1ZoScsoQSw/видео.html
The way I see it, there is mostly no essential duplication in my opinion. In a service you might have something like UpdateProduct. But updating the product is actually part of different business needs: increasing quantity, updating price, changing description. In most cases developers will try to fit all of these in an "UpdateProduct" method. Even if the way you update is the same that's still accidental duplication.
Yes. I've seen examples where people use MediatR handlers and inject the "traditional" services which is in my opinion terrible. You're just adding complexity layers without solving any real problem.
Fully agreed. Now also ditch the idea of wrapping EFCore's DbContext with repositories and just use EF directly in the handlers. Forget the pointless idea of unit testing repository methods, instead use docker to spin up a db and write integration tests using the real deal.
@@Codewrinkles we both missed that I already watched and commented it xD As I mentioned, I like the approach! Now next step is to realize that with Verticle Slices based on features there is no real need for layers with multiple projects. You have your Handlers that pulls and pushes Data between Infrastructure and Core (Smart Domain + Application) and that's it. A-Frame architecture. That is something I want to explore more going forward. I admit I have no production ready application experience with this yet, but I am working on it. As you wrote it somewhere: I am not reinventing the wheel. I read about this low ceremony concept from Jeremy D Miller
That's a tricky question. As the naming also implies they are route handlers and therefore a concept that knows about the http request-response pattern. Conceptually they are the equivalent of controller actions. So, the question is: would you consider the controller action as a handler and put everything there? In very simple applications that might be ok. In most of the applications you might want to keep your controller actions and/or your route handlers as clean as possible. I think the most common example for what I describe in the video are MediatR request handlers. Although one can easily implement this type of handlers also without MediatR.
I just want to add that I'm not re-inventing the wheel here. There were several other more notable people that talked about this issue, including Jimmy Bogard. In this video I just shared my experience where me and the teams I was working it managed to make some apps more maintainable which resulted in some very happy customers.
That's great, I was expecting at the end the same logic written in separated handlers, but the explanation as it is for me is now clear by what I have learned from your videos.
I have plenty of videos in the software architecture playlist where I implement handlers as well as in the livestreams where we buit the CwkSocial API.
Thank you for the video.
I largely agree with the design of handlers and use them myself.
However, this is like one of those discussions like "don't use repositories / always use repositories" where context matters.
Using your example where there is a payment service and a finance service, there is also some logic encapsulated in customer service somewhere.
Refactoring these to use handlers does not escape the problem that your payments handler and your finance handler at some point will require to fetch a customer, logic that already exists in the customer service.
What options (rather than copying and pasting code from the customer service) do you have if you will not create some sort of customer service that will be injected into both the customer handler, the finance handler and the payments handler?
I agree here that not all problems are solved.
@Codewrinkles I still can't use this approach with handlers because I can't understand and nobody explains how to avoid code duplication.
If I need to get a product by id with EF, should I just copy code from another handler? I think we must have some wrappers, because later we introduce soft delete and we should fetch by id and not deleted.
That problem can be solved with an extensions for DB Context. But we should always remember that they should be highly reusable with minimal dependencies.
What do you think about the idea to create service and repository per feature? In scope of VSA we can have service and repository dedicated to specific feature and cannot be used in other features. In this case we still can keep clean boundaries like with handlers and share code with a DB Context extensions.
But the benefits are:
- service/repository approach is well known and easy to follow;
- no need to create tons of classes like request/handlers;
- easy to debug;
- can be used with Clean/Onion architecture.
Really looking for your answer.
Some code might have helped to understand why a handler is better and how does it fixes the problem. A handler is still a "service", more like a dedicated one. Does it matter if you call it handler or service? I don't think the mess you described is because you used a "service", it's because that service is bad designed.
Services will always end up being bad designed because of the DRY obsession. It's not a matter of "if" but a matter of "when" this start happening. On the other hand, I agree with you. If you would have one and only one service method that is responsible to handle just one and only one application action, it would be the same. This, however, defeats the purpose of the main selling point of services, which is "code re-utilization".
@@Codewrinkles Yeah, sometimes some thing which looks 'new' to me is nothing but some old principle in the disguise of some fancy new word. I think handler is nothing but the SRP.
Thanks for the great material! I just wanted to clarify some things. In my mind the main question on this video could be trsnslated to: " Orchestration/Process msnagement or Choreography". This means that if you chooose the first, there is a specific central place to handle the flow of a specific request, in the second case there isn't and the changes in one context are propagated via events. The main advantage of the second approach seem to be the decoupling which provides the flexibility of adding new handlers to create new flows without having to make changes to a central place. One downside seems to be the absence of a centralised place to have the knowledge of the application flow.
There's literally ZERO mid-sized project I have worked on or refactored in which we need to orchestrate things in a such a complex way. Bare MediatR notifications give you everything you need. But if the app is very complex then we'd probably be in a place where we'd need to add some extra complexity and implement messaging patterns.
great video, are you going to show handler implementation?
I have several videos that implement handlers. There's the software architecture playlist for that.
I don't think they have to be mutually exclusive, you can have handlers that consumes services, like for example to avoid calling a handler inside another handler, in that case to reuse the same logic U have to create a service that's gonna be called from multiple handlers. Thanks for ur content
In my opinion the example you have is not optimal. This setup will lead to the exact same problem with state mutation across boundaries. You should use notifications to notify anybody else in the app that something of interest might have happened.
The only type of services I think it's ok to use in handlers are infrastructure type of services, like sending email, uploading files and so on.
@@Codewrinkles : Hi, very nice videos. I just stumbled upon your video about "aggregates" and "domain services". How this correlates with this video?
How does handler implementation handle the code duplication issue?
Of there are different reasons for change, then there is no code duplication issue as the SRP is not violated. The "code duplication" obsession causes more problem than it solves in most of the cases. ruclips.net/video/v1ZoScsoQSw/видео.html
@@Codewrinkles services could be trying to avoid the essential duplication rather than accidental duplication.
The way I see it, there is mostly no essential duplication in my opinion. In a service you might have something like UpdateProduct. But updating the product is actually part of different business needs: increasing quantity, updating price, changing description. In most cases developers will try to fit all of these in an "UpdateProduct" method. Even if the way you update is the same that's still accidental duplication.
Do you mean creating handlers for these scenarios only or completely replacing the services with handlers in entire application?
Yes. I've seen examples where people use MediatR handlers and inject the "traditional" services which is in my opinion terrible. You're just adding complexity layers without solving any real problem.
Fully agreed. Now also ditch the idea of wrapping EFCore's DbContext with repositories and just use EF directly in the handlers. Forget the pointless idea of unit testing repository methods, instead use docker to spin up a db and write integration tests using the real deal.
I have just published a video about this yesterday :)
@@Codewrinkles I am lagging a bit behind with your content, going to make a coffee and watch it!
Here's the link: ruclips.net/video/F7DtfSsDsjk/видео.html
@@Codewrinkles we both missed that I already watched and commented it xD
As I mentioned, I like the approach!
Now next step is to realize that with Verticle Slices based on features there is no real need for layers with multiple projects. You have your Handlers that pulls and pushes Data between Infrastructure and Core (Smart Domain + Application) and that's it. A-Frame architecture. That is something I want to explore more going forward. I admit I have no production ready application experience with this yet, but I am working on it. As you wrote it somewhere: I am not reinventing the wheel. I read about this low ceremony concept from Jeremy D Miller
I tried to go VSA in a production app and for me it was a traumatizing experience :)) For the team also :))
By handler do you mean , for example, putting the logic in a min api handler?
That's a tricky question. As the naming also implies they are route handlers and therefore a concept that knows about the http request-response pattern. Conceptually they are the equivalent of controller actions. So, the question is: would you consider the controller action as a handler and put everything there?
In very simple applications that might be ok. In most of the applications you might want to keep your controller actions and/or your route handlers as clean as possible.
I think the most common example for what I describe in the video are MediatR request handlers. Although one can easily implement this type of handlers also without MediatR.
awesome video Mr.Dan
could you talk about Hi/Lo Algorithm? and when and how to use it?
In 19 years of development I never had to use/implement the Hi/Lo Algorithm mysellf. I wonedr what's your use case for it?
@@Codewrinkles just curious to know how to use it and when to use it. but it's ok I know you have more important topics to tell us about
that makes sense
In consequence we would end up with applying CQRS.
Handlers = Manager services