Build a scalable and fault tolerance application — Part 2— Add business logic
In the last post, we created a microservices application using JHipster. At this moment the application doesn’t have any business logic in it, but we’ll add it in the next sections of this post.
The goal of the application is to let you to create an account, create a post about a country or city where you traveled, search after other posts, to give a review to a post and of course a statistic page for the admin where he’ll find out how many users have created an account in the past days, how many posts where created and which countries or cities were most visited until now.
Let’s start with Users microservice, when a user create an account, we should keep extra informations about him as: where he’s from , date of birth, email, additional social platforms (e.g. facebook, twitter, youtube) and countries which he had visited.
Because we are following BDD ( Behavior Driven Development ) and TDD ( Test Driven Development ) development methodology in this project as a good practice, we’ll start to write the application behavior in Cucumber tool.
Cucumber is a free, open source platform, designed to support BDD development, which bridge the gap between business and technical people by collaborating on executable specifications.
Gherkin is the language used by Cucumber, which use specific keywords (e.g. Given, When, Then, And, But) to give structure and meaning to executable business specifications.
Behavior Driven Development (BDD) uses human-readable descriptions of software business requirements which can be used to test the features of the application.
For Users microservices will start first with the feature description for creating a user. The informations will be received from Gateway through a Kafka topic.
All those steps (Given, When, Then) will be implemented, so that each step will have a specific implementation in Java.
After we created those steps we can start implement the feature by creating the corresponding components (Repository, Service and Controller) on each layer of the application and the corresponding POJOs (Entity and DTO). This kind of arranging the code is call layer architecture.
The same approach will be done also for the next features of this component: update user information, read user information and delete user information.
The Posts microservice will be responsible for CRUD operations over posts, created by user, about a country which he has visited. Given that it is not a complicated logical business, we will not go into more detail. It’ll be used the same approach for the development as it was used for the Users microservice.
The statistics microservice will collect the information regarding when a user created a new account, when a new post was created and about what country. The development will be done in the same way.
All the operations will be available through REST endpoints, so that to be easy to integrate them in a nice user interface written in React.js and add it to Gateway microservice.
At the final the flow of the application will going to look like this:
