Identifying microservice domains for the business

This is the time to understand the business domain that will be developed in the book. The domains are contained in our monolithic application. Let's recap how it is composed. Our monolithic Django is organized into three Django apps that are as follows:

• News
• Recommendations
• Users

It is important to understand that in this context, because of how Django is designed, Users and AAA are coupled, and we have seen that this is not good when it comes to microservices.

Another point is that news will not necessarily result in a single microservice; we can create microservices-varied news with the type of news. This would facilitate the targeting of APIs  and scalability for each different type of news content. On our portal, we have sports, politics, and celebrity news. If a new theme is developed, a new News microservice will be created for this theme. This approach enables something like z-axis scalability for that part of the application.

At first, our domains will be divided into the following categories:

• SportNewsService
• PoliticsNewsService
• FamousNewsService
• RecomendationService
• UsersService
• AAAService (Optional)

Of course, new fields can be added and others can be removed; limiting the view of this microservice is our big target.