In many cases, the microservices perform more tasks than they should. Apparently all is well and deployment is simplified, but in fact, the domain is fat. Microservices do not have that name because they are a small application, but because they have a small and simple business domain. When a microservice has limitations in certain fields, it means that the application was initially constructed on a small monolith.

Thinking about our application, the news portal, a good candidate for a microservice is users. It makes perfect sense to build a microservice administering user data. However, usually, in a monolithic application, the layer on the users has a strong connection with AAA (Authentication, Authorization, and Accounting).

When it comes to microservice data, users, and AAA are an undesired coupling. This is mainly because the whole process of AAA is not restricted only to end users, but for clients such as mobile, frontend, and consumer APIs. In this case, the User microservice represents a fat domain.

The division of this fat domain can be held in two parts; the first part is AAAService and the second is UserService. Another approach is the AAA responsibility for a gateway API. The functional scalability and features of implementation with these separate domains is much more interesting for the growth of the product as a whole.

Understanding the size and limits of the domains is clearly critical to the growth and scalability of the final product.