I’ve been hearing that some people are uncomfortable with choreography because their old orchestration code is no longer in one place, making it harder to reason about and debug.
Does anyone here feel the same way? I don’t have experience with it when it comes to working with event sourcing. I imagine that if you maintain logs that include your correlationId throughout the transaction then you’ll be able to debug just fine. What are the challenges in real life?
I think it depends on how you organize things currently.
Are you already following best practices from Clean Code and making sure your methods or functions are simple?
What about the SOLID principles and applying single responsibility, say at the class level?
Then I would wonder how you’re organizing your code. Are you using a multi-module maven project in Java? Or planning on having different code repos for each application?
Also, are you already doing microservices? Because I have seen cases where microservices have evolved into the orchestration pattern. This can be a little simpler to unwind and to refactor. But if you’re going from Monolith to microservices with the intent of doing choreography, this can be more of a paradigm shift for an organization new to microservices.
For logging, you can use something like ELK stack to centralize all your logs. Then you can search for the correlation id.
For deployments, you could consider something like helm charts to manage the deployments for all the new services.
I think the best way to make the switch is to use the Strangler Pattern
So this might be a lot to consider, but the desire to keep things simple at all levels is still the same principle.
Hope this helps
Thanks
Zach