Modularity by Microservices
1 like255 views
This document discusses how Domain-Driven Design (DDD) principles can help decompose monolithic applications into microservices. It outlines key DDD patterns like bounded contexts, aggregates, and domain events that can be used to identify microservices and define integration between them. Transactional consistency should be used within microservices while eventual consistency is used between microservices. Design rules are presented for aggregates, events, and integration of bounded contexts. Microservices should align with bounded contexts, use asynchronous communication, and have independent data storage. DDD provides essential lessons for modularization, resilience, and scalability in microservice architectures.
Modularity by Microservices
- 1. Modularity by Microservices Tech Festival #INGLovesIT How can DDD help in decomposing applications in microservices? Bucharest, 7th of April 2017 ,
- 2. Agenda 2 What are microservices? Whats is DDD? Introduction to the most important DDD patterns Microservices revisited Conclusions: Design Rules
- 3. What are microservices? Source: https://www.martinfowler.com/bliki/MicroservicePrerequisites.html 3
- 4. Microservices characteristics* Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design *Reference: https://martinfowler.com/articles/microservices.html 4
- 5. Microservices benefits Agility in development Better understanding of the architecture Resilience in a production Independent scalability of microservices Independent deployment of microservices Fault tolerance (failures in a microservice can be isolated from other microservices) 5
- 6. Levels of abstractions 6 microservices modules packages classes The same concerns (high cohesion, low coupling, separation of concerns etc.) apply at all levels. “If people can’t build monoliths properly, microservices won’t help.” Simon Brown
- 7. From monolith to microservices 7
- 8. Problem #1: Data Services as Microservices Layered Coupling Communication Coupling The service is not autonomous 8
- 9. Problem #2: Synchronous Integration between Microservices Temporal Coupling Behavioral Coupling* The services are not autonomous Complex and unreliable compensation logic Circuit breaker, timeouts, retries etc. are of limited use *Reference: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/ 9
- 10. How do we identify microservices? 10
- 11. Introduction to DDD Strategic Design: bounded contexts context map Tactical Design: entities values aggregates aggregate roots Repositories services domain events application services 11 Reference: Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley, 2003, Vernon, Vaughn. Implementing Domain-Driven Design. Boston: Addison- Wesley, 2013.
- 12. Aggregate Design Rules Cluster entities into aggregates according to the invariants that really need to be guaranteed Reference other aggregates only by root id (including ones from the same bounded context) Limit aggregates to small set of data Modify in one transaction only one aggregate instance 12
- 13. Domain Events An event captures the changes in the state of a single aggregate Events are immutable They get published by the aggregates and contain the associated aggregate root id Each event should have a unique id that could be used for de-duplication 13
- 14. Integration Rules between Bounded Contexts Via a publish/subscriber messaging infrastructure The bounded contexts interested in the data maintained by other bounded contexts subscribe to the relevant events Integration via events is applicable also between different aggregate instances from the same bounded context Transactional Consistency within aggregate boundaries Eventual Consistency between different bounded contexts and between different aggregate instances 14
- 16. Messaging Requirements in View of DDD Support for publish/subscriber pattern Support for competing consumers pattern Persistence and Durability At-least-once message delivery Partial message ordering (per aggregate) 16
- 17. Application Technical Requirements in View of DDD Transactional semantics when publishing events Events deduplication on subscriber-side for achieving exactly-once delivery semantics 17
- 20. Packaging 20 Separation of business concerns from technological concerns Apply Dependency Inversion Principle at domain boundaries
- 22. Microservices Design Rules 1 microservice = 1 bounded context = 1 deployment unit 1 operation = 1 transaction = 1 aggregate Prefer asynchronous communication between microservices over synchronous request/reply integration data replication over events Transactional consistency within a microservice / Eventual consistency between microservices 22
- 23. Microservices Architecture Decomposing application into loosely coupled services: - Explicit contract/ interface - Boundary alignment with business capabilities - Asynchronous communication between microservices - Microservices have their own storage (they are the authoritative source of data for their domain) 1 2 3 4 1 2 3 4 23
- 24. Microservices Benefits Agility in development Resilience in production Microservices can be scaled independently Data Scalability (Data Partitioning) Microservices can be deployed independently (different deployment options should be made available by the architecture). Failures in a microservice can be isolated from other microservices 24
- 25. Conclusions Microservices are mainly about design and only secondarily about technology Domain Driven Design offers essential lessons on: how to modularize your application in microservices how to achieve resilience how to achieve scalability 25
- 26. Thank you!