Project Architecture - Turbots/oraj-360-tool GitHub Wiki

Project Architecture

We've decided to implement a microservices architecture for the 360 tool. This might seem like (and most probably is) overkill for an application of this size, but think of it as a nice reference implementation of a microservice architecture based on Spring Boot/Cloud and the netflix stack (http://netflix.github.io/#repo).

For the front-end of the application we've chosen to work with AngularJS and Bootstrap. The front-end uses Bower and Grunt for dependency management and build automation.

Microservices

What are microservices?

A great article explaining what microservices are, can be found at http://martinfowler.com/articles/microservices.html

In the second paragraph of that article the following is said:
the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Our solution

General

In our case, the microservices architecture translates into the creation of multiple Spring boot applications which will be tackling certain business concepts. These applications will contain REST api's with support for hypermedia (level 3 in Richardson maturity level).

Creating REST services alone however, isn't enough. Employing a microservices architecture brings along a certain level of complexity. Best practices and design patterns have been established to handle these complexities and implementations of these solutions are available nowadays. We will be relying heavily on the netflix stack for providing us with operational components to help solve this.

The most common best practices in microservice architecture and the libraries used to implement these are listed in the table below:

Operational Component Provider
Service Registry Netflix Eureka
Edge Server Netflix Zuul
Circuit breaker Netflix Hystrix
Monitoring Netflix Hystrix Dashboard and Netflix Turbine
Dynamic routing and loadbalancing Netflix Ribbon
Centralized config Spring cloud config

Project structure

We chosen maven as our build and dependency management tool. We've created a project with a main pom.xml file which handles our dependency management and specifies the modules that are part of the application. Each module basically corresponds to a microservice (spring-boot application) or an operational component used to manage our microservices. You can find this pom.xml file here.

At the time of writing, these are the modules currently available:

  • config-server: Centralized config server using Spring Cloud config
  • service-registry: Service registry using Spring Boot/Cloud and Netflix Eureka
  • zuul: Edge server and centralized entrypoint using Netflix Zuul
  • hystrix: Circuit breaker using Netflix Hystrix
  • turbine: Circuit breaker streams aggregator. Basically a Dashboard where all circuit breaker monitoring data is aggregated into 1 view. Based on Netflix Turbine.
  • admin: Central administration application allowing us to view and manage all deployed microservices using Spring Cloud Admin.
  • common-utils: Common utils shared by all microservices.
  • common-model: Common model objects shared by all microservices. NOTE: Normally each microservice manages it's own domain objects. It's no best practice to share domain objects between microservices as this adds a certain level of coupling to the services. However, we chose to do this anyway for simple and general objects such as Address.
  • person-service: Microservice handling person business logic
  • timeline-service: Microservice handling timeline events business logic.

Useful resources

Development environment

Containerization

Another complexity that is being added to the project is due to the fact that there are so many microservices with their potentially very different development environments. To prevent each developer from having to install numerous applications, we decided to use containers and virtual machines which are automatically being provisioned. To accomplish this, we used Vagrant and Docker. More details on how we've applied these containerisation tools can be found in our Getting up and running

Useful documentation

Front-end

Tech stack

Yeoman

The front-end application will be developed using HTML5 technologies. The front-end was generated using a Yeoman Angular generator. This generator will generate an entire angular project for you. It will also create a best practice file structure which allows for extensibility and maintainability. After the initial project creation, Yeoman can also be used to generate additional parts of your code (controllers, routes, directives, etc...).

  • Yeoman can be downloaded here
  • The Yeoman Angular generator can be found here

CSS3 & SASS

The front-end application will make extensive use of CSS3. SASS will be used as CSS pre-processor to allow us to work hierarchically, use variables in CSS, etc...

More information in SASS can be found here

Bower

Bower is a Javascript package manager. It allows us to configure our dependencies (other Javascript libraries) in a json-file called .bowerrc. When running bower install these dependencies will be downloaded for us.

More information on Bower can be found here

Grunt

Grunt is a taskrunner. It's also very useful during development as it can serve your application on localhost. Also, all your projectfiles are being watched and in case of changes, these changes are immediately reflected in your application being served by Grunt.

More information on Grunt can be found here

⚠️ **GitHub.com Fallback** ⚠️