1. Gang of Four’s Design Patterns for Microservices
Hari
Thomas

2. So you want to use microservices?
image

3. Potential Migration Path

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

5. DDD - Landscape
With some domain boundaries color coded..

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

7. 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

8. 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

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

10. 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

11. API Gateway
Kong or Apigee or Zuul
Decorator
Facade
Proxy

12. Circuit Breaker

13. 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 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”

14. Event driven
Kafka or Java streams or Akka
Actor
Observer

15. CQRS

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

17. 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 :

18. The Goal

19. References
appcontinuum.io
better
(microservices infographic)