How do i manage coupling between handlers?

[hyuti]

There is a thought come to my mind when i came across your project. That is what if there is a case in which we have coupling between handlers. For instance, before i create a product named "Foo", i have to check whether if a product named "Foo" already existed, so in this case, i come up with the following approach: I think i will call another handler such as get_product_by_name to get me through this. I assume get_product_by_name as a feature. So this approach leads to couple between handlers. So my question is how do we manage this kind of coupling? Btw, your project is really great, it is really a helpful resource for people like me who like to learn about microservice architecture.

Thanks.

[mehdihadeli]

Hi, thanks for your feedback, for validating something from another service in the real-time, we should use some sort of sync call and that could be a REST Api call or in the better implementation use a gRPC call (use handlers directly between services is not allowed but if handlers are in the same service it is valid, this is a sample for this case) for getting data from another service. This project is not complete yet, but I have this sample in the c# version of this project here and here

[hyuti]

Hi,

Well man, I think your c# version of this project is really amazing, thank for your contribution to make the community stronger :muscle:. As seen from c# version, did you use mediator pattern to decouple from handlers in the same service? If I am not wrong, we have made use of mediator pattern in 2 places, the first one is to decouple from controllers and the last one is to decouple from handlers. I also came up with this solution when I had to deal coupling between handlers. And I am not sure that would be a nice way but I did see your implementation in c# version of this project and now I am quite sure this would be a right way. Cause in my past projects which used clean architecture to structure my codebase, in that scenario I met a concept such as usecase as same as handlers we are dealing with. And I did jump into a problem which is a usecase depending on other usecases. At that time, I didn't have an idea of taking advantage of mediator pattern so I only used interfaces to decouple from them which is not a quite good way. what a fool me! :joy: Btw, thank for your brilliant idea. It really helps me out. :clap:

[mehdihadeli]

Hey, Yes, C# for now is more completed, yes exactly I use mediator pattern for decoupling between handlers in same service in both c# and golang version. Using mediator and cqrs are very good match and makes our app maintainable and more scalable from my opinion. It is not very common in the go use of cqrs, but in .net because application are more complex and business heavy it uses more. I've created a medaitor library in the golang for doing this, but it is your choice I'm ok with. Thanks for your feedbacks :)