Sharing API services

So far, in our example TAEDA application, we have focused on various domain information that is closely interrelated. As a lone developer, you can probably recall most of the API endpoints you created in one microservice when you come to utilize them in another microservice. However, in practice, we don’t develop in isolation. One of the key benefits of microservice architecture is the ability to divide and conquer by assigning smaller domains to different teams (or lone developers). In fact, we don’t want to limit the understanding of our APIs to just the teams associated with the main solution, but to any other teams that might be able to benefit from these same services.

Let’s imagine a scenario where there is an intent to conduct a study on transit foot traffic patterns and how they correlate with major sporting events around various cities. We already have many services designed to support the backbone of the transit management system...