So this may come off a bit broad and generalized, but after spending some time working around under developers, I've come to notice many different methods and design patterns. However, one big thing that sticks out to me is how mind-bendingly complex some of these relatively simple (logic-wise) classes can get.For example, I recently built a service that synchronizes data between SalesForce and Zendesk. Now there are a lot of different business rules that have to be taken into considerable, but I built the application around the MVVM code pattern.But once you dig in a bit deeper, you'll notice a lot of complexity and you start digging through a lot of classes to figure out quite what's going on.For example, here's a class diagram of my synchronization tool. Even a casual glance will be able to show some of the complexity, and it gets even more difficult when you dig into the actual code behind the individual methods. Not only are you interfacing between two separate APIs, you're also interacting with multiple protocols (SOAP and REST). Both of these services are prone to hiccups and failures, so fallbacks are necessary to automatically retry upon failure. Then you need to map all the fields correctly back and forth. From there you have to ensure that nothing else manages to fail either. Every single field is a possibility for failure, and each feature you add makes in exponentially complex.How can you mitigate some of this complexity?
How to mitigate complexity of fallbacks introduced to automatically retry upon failure?
c#;design patterns;theory;encapsulation