Microservices Patterns & Strategies

Pre-Requisites for Micro-services

Following are essential principles to evaluate if your applications can embrace micro-services based architectures, these are also outlined in MartinFowler's work on microservices pre-requisites

• Rapid Provisioning - how quickly you can provision
• Basic Monitoring - how quickly you can monitor & detect problems
• Rapid Deployment - embracing DevOps culture

Patterns

• Microservices Patterns
• Design Patterns for Microservices
• Saga Pattern - for Transactional services
• Mo -> Mi - role of Edge Gateway or API Gateway

Service Mesh

• Service Mesh Pattern using SideCar
  • Isolating application-networking functions from appliction code using Service Mesh (Istio & Envoy)
• Introduction to modern n/w load balancing/proxiying
• Simplifying micro-services with Istio

Best Practices

Strategies for breaking monoliths into microservices

• Good Presentation on concepts
• Best-practices-for-building-a-microservice-architecture
• [Data sharing between Micorservices](https://www.linkedin.com/pulse/code-better-ddd-bounded-context-microservices-balazs-hideghety
• Using CQRS/Event Sourcing

Choosing Bounded Context

Identify Domains and sub Domains as bounded context Model aggregates for each bounded context

Design Principles for Aggregates

Good article on Refactoring from Anemic Models to DDD Entities

• Identify aggregates for each bounded context

• Each aggregate will have one or more entities and value objects. The Aggregate root entity names the aggregate concept as a whole and has a global unique identity, its unique across all other aggregates. Inside an aggregate as a whole, consider it as a transaction boundry. An aggregate is a transactional consistency boundary. Inside an aggregate, everything must be consistent and upto-date at the end of transaction. No two aggregates will participate in a single transaction, each aggreage will be bound to its own transaction context and consistent within its own single transaction boundry.

• Identify root entity from the entities as aggregate root.

Rules of effective aggregate design

• Protect Business invariants inside aggregate boundary
• Design small aggregates
  • start from smaller aggregates to avoid possible overlapping transactional boundaries with large aggregates spanning multiple entities. Multiple users may modify different parts of large aggregate and cause consistency violations (one tx will fail while not the other)
  • large aggregates could potentially create large footprints in memory causing GC problems.
• Reference other aggregates by identity only
• Update Other aggregates using eventual consistency

Examples

• Worked Examples