Microservices are designed to offer greater agility and operational efficiency for the enterprises. My goals and principles for a microservice architecture are Continuous and faster delivery through DevOps, Built around business context (better business-developer coordination), Reduced cost, Independently deployable, Decentralized, Small and maintainable code.
Microservices is all about building around business domain or business context, creating decoupled code and making services loosely coupled, applying the single responsibility principle. A business context could be defined using DDD(domain driven design concept), It is something that a business does in order to generate value. A business context often corresponds to a business objective, e.g.
- Order Management is responsible for orders
- Customer Management is responsible for customers
Decompose by Subdomain
Decomposing an application using business capabilities might be a good start, but you will come across so-called "God Classes" which will not be easy to decompose. These classes will be common among multiple services, you can think of it as helper, utility and library functions.
Define services corresponding to Domain-Driven Design (DDD) subdomains. DDD refers to the application's problem space — the business — as the domain. A domain consists of multiple subdomains. Each subdomain corresponds to a different part of the business. For example, let's define subdomain for order management :
- Product search engine service
- Cart service
- Order post service
- Payment confirmation services
- Warehouse inventory services
- Shipping services
- Order completion service
Event Sourcing
Most applications work with data, and the typical approach is for the application to maintain the current state. For example, in the traditional create, read, update, and delete (CRUD) model a typical data process is to read data from the store. It contains limitations of locking the data with often using transactions.
The Event Sourcing pattern defines an approach to handling operations on data that's driven by a sequence of events, each of which is recorded in an append-only store. Application code sends a series of events that imperatively describe each action that has occurred on the data to the event store, where they're persisted. Each event represents a set of changes to the data (such as AddedItemToOrder).
Aggregator Pattern
It helps to address collaborate the data returned by each service, aggregate the data from different services and then send the final response to the consumer. This can be done in two ways:
- A composite microservice will make calls to all the required microservices, consolidate the data, and transform the data before sending back.
- An API Gateway can also partition the request to multiple microservices and aggregate the data before sending it to the consumer.
It is recommended if any business logic is to be applied, then choose a composite microservice. Otherwise, the API Gateway is the established solution.
Cloud Native for Microservices
Cloud native is a term used to describe container-based environments. Cloud-native technologies are used to develop applications built with services packaged in containers, deployed as Microservices and managed on elastic infrastructure through agile DevOps processes and continuous delivery workflows.
Service Discovery
A service registry needs to be created which will keep the metadata of each producer service and specification for each. A service instance should register to the registry when starting and should de-register when shutting down. There are two types of service discovery:
- client-side : eg: Netflix Eureka
- Server-side : eg: AWS ALB.
Comments