Thanks to the hype surrounding them, you undoubtedly have already heard about microservices. What is wanted worldwide through this approach is independent deployability and scalability. This can also be achieved through other approaches; see the Uncle Bob article.
Many companies nowadays have their solution built upon many of their own parts (services, jars, etc.). There are also numerous useful (and very often free) APIs available with which one would want to integrate, for example chats, maps, KYC and AML databases, PDF generation and data warehouses, to name just a few. These APIs form other parts of our final solution.
In the end, we end up with lots of parts and lots of dependencies. In terms of the functionality we are able to obtain, this is just great. On the other hand, the fact remains that we have dozens of parts with loads of dependencies which we have to deal with. Do we need a dependency graph of these parts? Yes, we absolutely do - it is extremely crucial. Without a dependency graph, one can get lost in the maze of dependencies and numerous integration problems can arise - the source of the worst headaches in IT.
So sure, we have an issue to deal with. But I content I have a very good solution - to have someone map out all of these dependencies in diagram form! But wait. In actuality, a large number of these parts and dependencies are constantly changing and changing very quickly. Sprint by sprint, it would be necessary to review the entire system (being developed by multiple teams through a variety of connectors, such as REST, SOAP, JDBC, JMS, etc.) and it’s likely that things may slip through the cracks at times. What’s more, everyone knows that the truth is always in the code, not in the documentation written by people in the office. But what if the documentation is generated from the code automatically? We then would have documentation with completely up-to-date information. A dream come true for every architect, analyst and deployment manager.
Once you write your connectors to other systems that are smart enough (easy retrieval of information concerning dependencies), you have won. It would then take just one click and you get the complete dependency graph.
We discovered this need early on at our company and now with each build of any part of our solution we generate a fully up-to-date dependency graph. The below is presented to give you a bit of an idea of how this would look in the form of an HTML page:
Should you decide to create and utilize your own dependency graph, you will quickly come to appreciate the minimal initial costs and effort it takes to make this idea reality. It’s important to bear in mind that the devil is always in the details. Being detail-oriented will help keep that devil at bay.