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:
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:
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.