OTRS overview

Based on microservice principles, we need to have separate microservices for each functionality. After looking at OTRS, we can easily divide it into three main microservices—the restaurant service, the booking service, and the user service. There are other microservices that can be defined in the OTRS, but our focus is on these three microservices. The idea is to make them independent, including having their own separate databases.

We can summarize the functionalities of these services as follows:

• Restaurant service: This service provides the functionality for the restaurant resource—create, read, update, delete (CRUD) operations and searching. It provides the association between restaurants and tables. This service also provides access to the Table entity.
• User service: This service, as the name suggests, allows the end user to perform CRUD operations on user entities.
• Booking service: This makes use of the restaurant service and the user service to perform CRUD operations on bookings. It will use restaurant searching and its associated table lookup and allocation based on table availability for a specified time period. It creates a relationship between the restaurant/table and the user:

The preceding diagram shows how each microservice works independently. This is the reason why microservices can be developed, enhanced, and maintained separately, without affecting others. These services can each have their own layered architecture and database. There is no restriction to use the same technologies, frameworks, and languages to develop these services. At any given point in time, you can also introduce new microservices. For example, for accounting purposes, we can introduce an accounting service that can be exposed to restaurants for bookkeeping. Similarly, analytics and reporting are other services that can be integrated and exposed.

For demonstration purposes, we will only implement the three services that are shown in the preceding diagram.