Chapter 3. Microservices for Helping Hands Application

"We learn by example and by direct experience because there are real limits to the adequacy of verbal instruction."

- Malcolm Gladwell, Blink: The Power of Thinking Without Thinking

Microservices are gaining popularity for internet-scale applications that target consumers. In this chapter, you will learn how to apply principles of microservices architecture to design a similar, internet-scale, fictitious application called Helping Hands that connects household service providers with consumers of services such as home cleaning, appliance repair, pest control, and so on. In this chapter, you will:

• Learn how to gather requirements and capture user stories to design the Helping Hands application
• Learn the importance of monolithic-first design
• Learn how to move towards a microservices-based design
• Learn how to use event-driven architecture with microservices

Design

One of the best ways to design a software system is to capture the business domain, its users, and their interaction with the system as a user story (https://en.wikipedia.org/wiki/User_story). User stories are an informal way of capturing the requirements of a software system. In user stories, the focus is on the end users and the interactions that are possible between the users and the system.

Users and entities

The first step in writing user stories for the Helping Hands application is to understand the users and entities of the system. Primarily, there are two users of the system—Service Consumers and Service Providers, as shown in the following diagram. Service Consumers subscribe to one or more services provided by the Service Providers. The core entity of the application is the service. A service is an intangible, temporal, and limited asset that providers own and provide to the consumers on-demand at a price.

 

Service Providers register one or more services with the system that...

Monolithic architecture

The Helping Hands application can be designed using a three-layered architecture of presentation, business logic, and persistence. Based on the domain model, there can be four main tables in the Helping Hands application database corresponding to each entity. There will be a single database that will store all the data in the designated table. The database must be accessible to all the components of the system. The business logic layer will have well-defined components based on the principle of Separation of Concerns (SoC). Components will address all user stories for the Helping Hands application.

Application components

To address the user stories, there will be three main components and two helper components, as shown in the following diagram. The Registration Component will manage all the user accounts and related CRUD operations. The Service Component will handle all service-related operations such as create, update, and lookup. The Order Component will help place...

Moving to microservices

The limitations of a monolithic architecture for Helping Hands can be addressed by separating out the components along with the database as a microservice. These services can then make informed choices about the technology stack and database that suit them well. These services can be developed, changed, and deployed in isolation as per the concepts of a microservices-based architecture. To identify the bounded context for the components of an existing monolithic application, it is recommended to look at the database access pattern and related business logic first, isolate them, and then look at the possibilities to isolate the components further based on business capabilities.

Isolating services by persistence

In the existing monolithic application of Helping Hands, the consumers and providers database tables are accessed by all the core components of the system, as shown in the following diagram. These tables are prime candidates for being wrapped around a service...

Workflows for Helping Hands

Data workflows are the backbone of any microservices-based architecture. They define the sequence of messages and events that are generated among the services to accomplish a desired task. A workflow may consist of both synchronous and asynchronous messages.

Note

Workflows shown in this section are only for explanatory purposes and do not conform to the exact semantics of sequence diagrams (https://en.wikipedia.org/wiki/Sequence_diagram). Details of authentication, authorization, validation, and error conditions have been omitted intentionally.

Service provider workflow

The service provider workflow consists of Service Provider, Lookup Service, and Alerting Service. The Service Provider Component exposes endpoints for users to create and update service providers for the Helping Hands application, as shown in the following diagram:

For the create operation, the Service Provider service first validates the input request for the required parameters and privileges, then...

Summary

In this chapter, we designed an application called Helping Hands, using the best software engineering practices. We started with a monolithic architecture and argued why a microservices-based architecture is well suited for the Helping Hands application. In the next part of this book, we will first take a look at the basic development tools and libraries that we will be using to build our Helping Hands application.