octo-andrero

Object-Oriented Analysis and Design with Applications by Grady Booch is my favorite one. It explains object oriented programming from the conceptual point of view. I would also suggest the design patterns book by the gang of fours by the same reason: this book teaches you to think in the object oriented way rather than describes object oriented languages features.

Because it's interesting and, probably, the easiest way to bring significant business value. Most of the problems and opportunities I saw lies somewhere on the border of different departments, technology stacks and abstraction layers. And so little people want to dive into this mess, because it requires knowledge from other domains to solve.

Thank you!

Could you share any examples of interactive documentation or tools to build interactive documentations? The only thing comes to my mind is Swagger / OpenAPI documentation pages from Spring that allows you to send the request.

The Knuth is great, for sure, and I encourage any efforts to build strong basement of fundamental knowledge. Still I would suggest you to change the focus. As a software engineer most of the time you won't implement complex generic algorithms. You will use them from libraries. These books will help you learn more about other important problems that software engineers face everyday:

- Design patterns: Elements of Reusable Object Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

- Test Driven Development by Kent Beck

- Code Complete (2) by Steve McConnell

Good engineers design according to requirements, great engineers challenge them.

I would suggest you to split the question into multiple:

1/ What should be communication pattern you need: synchronous calls via API, message brokers (you configure routing rules inside message broker) or stream of events.

2/ How you should structure the code that processes your data once you've received it somehow. This is the point where it's possible to start thinking about OOO and design patterns. Regarding your concern, looks like you mean premature abstraction. You may have N different code packages that do the integration and have nothing in common. This approach works well if you suspect that your integrations are going to evolve independently from each other. If you could provide some more details on what you're going to build I can help.