This chapter takes you from the design stage to the implementation of our sample project – an Online Table Reservation System (OTRS). Here, you will use the same design explained in the last chapter and enhance it to build the µService. At the end of this chapter, you will not only have learned to implement the design, but also learned the different aspects of µServices – building, testing, and packaging. Although the focus is on building and implementing the Restaurant µService, you can use the same approach to build and implement other µServices used in the OTRS.
In this chapter, we will cover the following topics:
- OTRS overview
- Developing and implementing µService
- Testing
We will use the domain-driven design key concepts demonstrated in the last chapter. In the last chapter, you saw how domain-driven design is used to develop the domain model using core Java. Now, we will move from a sample domain implementation to a Spring framework-driven implementation. You'll make use of Spring Boot to implement the domain-driven design concepts and transform them from core Java to a Spring framework-based model.
In addition, we'll also use the Spring Cloud, which provides a cloud-ready solution. Spring Cloud also uses Spring Boot, which allows you to use an embedded application container relying on Tomcat or Jetty inside your service, which is packages as a JAR or as a WAR. This JAR is executed as a separate process, a µService that would serve and provide the response to all requests and, point to endpoints defined in the service.
Spring Cloud can also be integrated easily with Netflix Eureka, a service registry and discovery component. The OTRS will use it for registration and the discovery of µServices.
Based on µService principles, we need to have separate µServices for each functionality that can function independently. After looking at the OTRS, we can easily divide the OTRS into three main µServices – Restaurant service, Booking service, and User service. There can be other µServices that can be defined in the OTRS. Our focus is on these three µServices. 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) operation and searching based on criteria. It provides the association between restaurants and tables. Restaurant would also provide the 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 User service to perform CRUD operations on booking. It would use the Restaurant searching, its associated tables lookup and allocation based on table availability for a specified time duration. It creates the relationship between the Restaurant/Table and the User.
Different µServices, Registration and Discovery
The preceding diagram shows how each µService works independently. This is the reason µServices 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 same technologies, frameworks, and languages to develop these services. At any given point in time, you can also introduce new µServices. For example, for accounting purposes, we can introduce an accounting service that can be exposed to Restaurant for book keeping. Similarly, analytics and reporting are other services that can be integrated and exposed.
For demonstration purposes, we will only implement the three services shown in the preceding diagram.