Gang of Fours Design Patterns for Microservices Hari

Gang of Four’s Design Patterns for Microservices Hari Ramamurthy @hari_ram Thomas Gamble @gambtho

So you want to use microservices? image credit: @alvaro_sanchez

Potential Migration Path

DDD - Landscape Layout the core domain. An example of such a model for a Retail order management system

DDD - Landscape With some domain boundaries color coded. .

DDD – Customer order A more detailed view of just the customer order

Takeaway It’s still a large domain, even if you slice it up Care needs to be taken to not add undue complexity when separating into bounded contexts As with microservices in general, DDD is all about balance

Creational Patterns On that Order domain model - Abstract Factory to create families of entities. - Singleton for some entities – like configurations - Builder to setup an order/configurator based order as a multi stage step

Service Discovery For instance Consul or Eureka (or platform provided) - Factory Pattern - Object pool

Structural Patterns On that Order domain model - The Order is a composite - Json/XML representations for most entities - Client interface specific Decorators and Adaptors - Aggregators services - Consumer driven contracts - Logic variations for discount calculations and representations by a Bridge

API Gateway Kong or Apigee or Zuul - Decorator - Facade - Proxy

Circuit Breaker

Behavioral Patterns On that Order domain model - Every api that accepts a json/xml and has varied behavior based on the actual content of the message, leveraging “command” pattern - Either synchronous or async - Extensive usage of “iterators” for multiple loops - Heavy usage of “Observer”, all the event based triggers like sending an email on an action on the order or notifying a down stream system on an action like a cancellation. - “Chain of Responsibility” as we step through to the appropriate class or the appropriate micro service to handle an action for a specific scenario. - Delegating to the correct domain specific logic if a specialized one exists, like online specific cancellation rules. - Scratch pad for uncommitted change or database’s uncommitted transaction on orders would be a representation of “memento”

Event driven Kafka or Java streams or Akka - Actor - Observer

CQRS

Therefore. . Start with monolith - drivers license Organize team effectively Service discovery or Centralized Router Interservice communication – - circuit breaker Decentralized data issues - DDD

In summary Make your life easier by not reinventing the wheel Improve your object-oriented skills Recognize patterns in libraries, languages and technologies (or the need) Use the power of a shared vocabulary Find truth and beauty Credit : https: //www. oreilly. com/ideas/5 -reasons-to-finally-learn-design-patterns

The Goal

References https: //www. oreilly. com/ideas/5 -reasons-to-finally-learn-design-patterns http: //www. oodesign. com/object-pool-pattern. html http: //microservices. io http: //martinfowler. com https: //www. nginx. com/blog/building-microservices-inter-process-communication appcontinuum. io http: //nordicapis. com/microservices-architecture-the-good-the-bad-and-what-you-could-be-doingbetter https: //www. nginx. com/blog/service-discovery-in-a-microservices-architecture http: //www. slideshare. net/alvarosanchezmariscal/stateless-authentication-for-microservices https: //www. nginx. com/blog/building-microservices-using-an-api-gateway https: //dzone. com/refcardz/getting-started-with-microservices https: //pivotal. io (microservices infographic)