Micro Service Chassis
Introduction
Any new application development starts with setting up a base project template that addresses cross-cutting concerns. It is usually a few day's efforts to come up with a working version of such a template. Not having a predefined template may considerably affect microservice development in terms of effort and quality considering the number of services that need to be developed.
Using a shared artifact like this may affect the autonomy of individual microservice teams as it put restrictions on the way a microservice can be built but such restrictions can often help ensure a basic quality of the overall product.
This section describes the features and overall approach for building Microservice chassis.
1.Project Organization (Layered Architecture) — A layered architecture lets you organize the application into different layers. Each layer focuses mainly on a single or similar concern. Please refer to the 'Layered Architecture' section for more details.
2. Build System — Predefined build configuration with basic project dependencies and build plugins.
3. Hardened container image template —A container template for building the microservice image.
4. Application Configuration — Support for managing application configuration across different environments.
5. API Documentation — Open API specification-based automated API Documentation.
6. Health Checks /Liveness Probe — Lightweight endpoint for checking individual microservice health.
7. Readiness Probe — Endpoint for validating basic application functionality to check if a service is ready to receive traffic after starting up.
8. Metrics — Endpoint for collecting application metrics for monitoring.
9. Service discovery — Support for client-side service discovery using client libraries.
10. Fault tolerance — Circuit breaker pattern implementation for avoiding cascading failures due to dependency (service) outage.
11. Distributed tracing — Monitor and profile applications for troubleshooting performance-related issues.
12. Authentication — Support for token-based authentication (OIDC).
13. Authorization — Support for token-based authorization. Align with the RBAC model.
14. Data Caching — In-memory and distributed caching integration.
15. Messaging Support - Asynchronous communication support over mainstream messaging infrastructure.
Layered Architecture
A layered architecture lets you organize the application into different layers. Below are the design considerations made while adopting layered architecture in our microservice chassis.
- Separation of concerns. Each layer focuses on similar concerns.
- Low coupling between layers and high cohesion within them.
- No circular references between layers.
- The domain or Business layer should only use an abstraction of infrastructure/technology services.
- Layers should be independently testable.
- Lower layers should not depend on the upper layers.
- Each layer should hide its implementation details. Always uses standard interfaces for communication between them.
It is difficult to enforce a predefined set of layers in all kinds of applications. Here are some of the templates that can be served as a starting point for your projects. Since stateful Rest API based services serve the majority of the use cases, special attention is given to it.
Simple Rest API Template
This template can be used for building microservices where the business domain is comparatively simple. Adopt this template if the development team is relatively inexperienced.

REST Client
The REST client is automatically generated by the build process. This library can be used for making RPC like calls to the microservice from external systems.
Interfaces Layer
This layer exposes service endpoints for external systems to integrate. RESTful web service endpoints, messaging endpoints, data serialization and data transformation, etc are the main responsibility of this layer.
Service Layer
This layer contains business services. Complete business logic resides here. Since business logic should not directly use a technology service, an abstraction/interface for the persistence layer is defined here.
Repository Layer
This layer implements a repository pattern. The definition of individual repositories is defined in the service layer hence this layer has a dependency on the Service layer.
Common Layer
Code related to all other cross-cutting concerns is placed here. This layer can be added as a dependency to all other layers.
DDD Rest API Template
Domain-Driven Design (DDD) is a design technique used for developing large and complex software applications. A detailed explanation of this pattern can be found under the ‘Application Decomposition’ section. Use this template if the problem domain is relatively rich and complex.

Interfaces Layer
This layer exposes service endpoints for external systems to integrate. RESTful web service endpoints, messaging endpoints, data serialization and data transformation, etc are the main responsibility of this layer.
Application Layer
This is a thin layer that coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress.
Domain Layer
This layer contains information about the domain. This is the heart of the business software. The state of business objects is held here. Persistence of the business objects and possibly their state is delegated to the infrastructure layer.
Infrastructure Layer
This layer acts as a supporting library for all the other layers. It provides communication between layers, implements persistence for business objects, caching support and all other cross-cutting concerns.
Experience API Template
Experience APIs are usually built in order to custom-tailor data for different types of client applications. These APIs won’t have their own data sources. They talk to downstream domain APIs (usually third-party), transform the response in such a way that it can be easily consumed by its clients. It is used while integrating third-party systems to a custom made UI or for establishing an anti-corruption layer etc. Though an additional layer (below service layer) with the repository pattern can be used in this scenario, it is intentionally avoided to simplify the architecture.

Interfaces Layer
This layer exposes service endpoints for external systems to integrate. RESTful web service endpoints, messaging endpoints, data serialization and data transformation, etc are the main responsibility of this layer.
Service Layer
This layer contains data transformation logic. Usually, experience APIs won't have business logic as they are a thin layer over functional domain APIs.
Common Layer
Code related to all other cross-cutting concerns is placed here. This layer can be added as a dependency to all other layers.
