![Event Driven to Event Intrusion
Distributed [big ball] Monolith
leading to a](https://image.slidesharecdn.com/eda-eventcentric-250604160655-3d07dfda/85/Eliminate-the-complexities-of-Event-Driven-Architecture-with-Domain-Driven-Design-29-320.jpg)
![Event [Centric] Care!](https://image.slidesharecdn.com/eda-eventcentric-250604160655-3d07dfda/85/Eliminate-the-complexities-of-Event-Driven-Architecture-with-Domain-Driven-Design-77-320.jpg)
More Related Content
Similar to Eliminate the complexities of Event-Driven Architecture with Domain-Driven Design (20)
More from SheenBrisals (15)
Recently uploaded (20)
Eliminate the complexities of Event-Driven Architecture with Domain-Driven Design
- 1. Eliminate the Complexities of Event- Driven Architecture with Domain- Driven Design! Sheen Brisals Architect, Author, AWS Hero, Team Topologies Advocate
- 3. Coupling
- 6. If any two entities are connected, they are coupled. Celestial bodies affect each other through gravitational forces — they remain coupled despite the substantial distances between them. - Balancing Coupling in Software Design
- 8. If everything is somehow coupled, why is coupling considered as bad?
- 9. Legacy ecomme rce Tax System VPC Node.js + React Elastic Beanstalk container Server contents Server contents Tax Products CRM Fulfillment Rewards VPC Gateway Corporate data center Server contents
- 10. Legacy ecomme rce Tax System VPC Node.js + React Elastic Beanstalk container Server contents Server contents Tax Products CRM Fulfillment Rewards VPC Gateway Corporate data center Server contents 503 Service Unavailable
- 11. Tightly coupled!
- 12. Tight coupling is Bad Loose coupling is Good A high degree of interdependence between different components or modules in a system. A minimal dependency exists between different components or modules in a system.
- 13. To loosely couple or connect… Independent systems Messages (Queues) Events (Pub-Sub)
- 15. sheen-brisals sheenbrisals sbrisals.medium.com #TheServerlessBook #TheSpeakerBook Architect at Sky AWS Serverless Hero Team Topologies Advocate Sheen Brisals leanpub.com/TheSpeakerBook
- 16. 1. A quick intro to EDA Agenda 3. DDD: How can it (& others) help EDA? 2. EDA: Mistakes & Pains 4. Takeaways
- 17. Service A Service B Invokes with a request Returns with a response Service C Service D Submits a batch job Acknowledgment Job status Updates Polls Service C Service D Submits a batch job Acknowledgment Notification Service E Service F Messages Sends a message Receives a message
- 18. Event-driven architecture (EDA) is an architectural concept that uses events to communicate between applications asynchronously.
- 19. The elements of EDA Customer accounts Finance Customer service Event broker account created account created account created • Event producer • Event consumer • Event broker or bus • Events account deleted account deleted
- 22. EDA is Awesome!!
- 24. Mistakes and Pains of EDA
- 28. Start-up teams Teams new to EDA Too focused on the MVP No strategic vision
- 29. Event Driven to Event Intrusion Distributed [big ball] Monolith leading to a
- 30. System A System B System C System D System E Event Broker Resources / Services
- 31. System A System B System C System D System E
- 32. System A System B System C System D System E
- 33. System B System C System D System E Engineering freedom! Feature blindness Quick-win mindset No design principles High cognitive load
- 34. The Unavoidable Duplicates Oversight by Engineers and the
- 35. Customer accounts Finance Customer service Event broker account created account created account created account deleted account deleted Network outage Consumer unavailable Quota exceeded Rate limited
- 36. Customer accounts Finance Customer service Event broker account created account created account created account deleted account deleted Network outage Consumer unavailable Quota exceeded Rate limited Lack of knowledge & care No event identity No error handling - DLQs No flow control Business implications
- 39. { { "metadata": { ... }, "data": { “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Bloke", “email": “[email protected]", “dob": “10121999" } } } { { "metadata": { ... }, "data": { “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Bloke", “email": “[email protected]", “dob": “12101999" } } } MM DD YYYY DD MM YYYY Implicit Change
- 41. { { "metadata": { ... }, "data": { “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Blog", “email": “[email protected]", “dob": “10121999" } } } { { "metadata": { ... }, "data": { “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Blog", “email": “[email protected]", “created_on": “15022025“, “age": 25 } } } Explicit Change
- 43. Event broker account created account created account created Customer accounts Finance Customer service Visible consequences No event contract No event schema Low team morale Loss of revenue
- 46. In a distributed event-driven system, do we even have two ends?
- 48. Checkout Payments Orders Rewards Shipping No trace identifiers No structured logs No clear boundaries Lack of observability tools Wasted engineering time
- 51. What is not complex in our lives?
- 52. Kitchen notification Food dispatch Customer notification Checkout Route planner Instore orders Online orders More! Stock Phone orders Loyalty Menu Driver tracking Payments Order management Personalization 3rd Party systems Customer service
- 53. Law of Conservation of Complexity Every application has an inherent amount of complexity that cannot be removed... Instead, it must be dealt... - Larry Tesler (Tesler’s Law)
- 54. Is there a way to untangle the complexities of EDA?
- 55. The most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it into pieces that can be solved independently.
- 57. For every complex problem there is an answer that is clear, simple, and wrong. - H. L. Mencken
- 58. To prevent entangled architecture… the system must be decomposed. business untangled Remember Conway’s Law?
- 59. Domain-Driven Design It’s not a book. It’s an industry!
- 60. Domain-Driven Design DDD is a development approach to model business domains to design and build robust and evolvable software systems. DDD is a collection of patterns, principles, and practices, which can be applied to software design to manage complexity.
- 61. Domain: Ecommerce Domain: Insurance Domain: Banking A domain is an area of knowledge, expertise, or activity a company or business specializes in. Domains
- 62. Domain: Ecommerce Subdomain: Products Subdomain: Payments Subdomain: Orders Subdomain: Loyalty Within a domain, a subdomain is a fine-grained area of business activity. There will be multiple subdomains in a business. Subdomains Core subdomains Generic subdomains Supporting subdomains
- 63. Domain: Ecommerce Subdomain: Products Subdomain: Payments Subdomain: Orders Subdomain: Loyalty Bounded contexts Model boundaries Evolve independently Work together BC Stock User Payments BC Cart Shopper Rewards BC BC Bounded context defines the physical and ownership boundaries.
- 64. But how do you find out the model boundaries?
- 65. EventStorming
- 66. EventStorming is a collaborative, non-technical workshop that brings together business and technical people to discuss, ideate, brainstorm, and model a business process or analyze a problem domain.
- 67. Alberto Brandolini, the inventor of EventStorming, drew his inspiration from Domain-Driven Design!
- 68. It’s developers’ (mis)understanding, not domain experts’ knowledge that gets released in production. - Alberto Brandolini
- 69. Time Domain Event Command redeem reward Aggregate reward Actor customer reward_redeemed emits acts on order update order Pivotal Event Boundary Big Picture EventStorming (Domain-level EventStorming) Design Level EventStorming (Development-level EventStorming)
- 70. To control event intrusion… the boundaries must be guarded.
- 71. To guard a system boundary, you require… People: to own the product Principles: to guide the team Practices: to achieve fast flow
- 72. Provides a model for organizing teams to enable autonomy and fast flow of value.
- 73. Domain: Ecommerce Subdomain: Products Subdomain: Payments Subdomain: Orders Subdomain: Loyalty Team Topologies Enabling Teams Platform Teams Stream-aligned Teams BC Stock User Payments BC Cart Shopper Rewards BC BC Complicated-Subsystem Teams
- 74. Dev Prod Test Pre- prod Autonomous Team Payments - Bounded Context Operation Owns Operates
- 75. To prevent breaking changes… establish communication contracts.
- 76. API contracts – Synchronous Communication Event Contracts – Asynchronous Communication
- 78. An event is something already happened. A change in the system’s state. An immutable capsule of data about the change.
- 79. To provide context… an event must belong somewhere.
- 80. A domain event describes something significant that has happened in the business domain. Domain Events account_created order_placed payment_authorized Customers Orders Payments
- 81. { “event": { “domain”: ”customers”, “subdomain”: ”accounts”, “service”: ”registration” “name”: ”account_created” “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Bloke", “email": “[email protected]", “dob": “10121999" } } A customer account was created in the system!
- 82. To uniquely recognize an event… an event must carry a version and an identity.
- 83. { “event": { “version”: 1.0, “created_at”: ”2023-08-29T12:10:21Z”, “domain”: ”customers”, “subdomain”: ”accounts”, “service”: ”registration” “name”: ”account_created” “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Bloke", “email": “[email protected]", “dob": “10121999" } } The event now has a version!
- 84. { “event": { “version”: 1.0, “created_at”: ”2023-08-29T12:10:21Z”, “event_id”: ”abc-xyz”, “domain”: ”customers”, “subdomain”: ”accounts”, “service”: ”registration” “name”: ”account_created” “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Bloke", “email": “[email protected]", “dob": “10121999" } } The event now has an identity!
- 85. { “event": { “version”: 1.0, “created_at”: ”2023-08-29T12:10:21Z”, “event_id”: ”abc-xyz”, “trace_id”: ”12c-x89”, “domain”: ”customers”, “subdomain”: ”accounts”, “service”: ”registration” “name”: ”account_created” “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Bloke", “email": “[email protected]", “dob": “10121999" } } The event now has a trace identifier!
- 86. To handle duplicate events… implement idempotency measures.
- 87. Customer accounts Finance Customer service Event broker account created account created account deleted Event index store Is event in the store? Lookup Log details and ignore YES NO Store the event Outbox pattern Storage-first pattern
- 88. Devise a common event structure…
- 89. { “event": { “version”: 1.0, “created_at”: ”2023-08-29T12:10:21Z”, “event_id”: ”abc-xyz”, “trace_id”: ”12c-x89”, “domain”: ”customers”, “subdomain”: ”accounts”, “service”: ”registration” “name”: ”account_created” “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Bloke", “email": “[email protected]", “dob": “10121999" } } Mixes functional and non- functional data.
- 90. { "detail": { "metadata": { // Details about the event }, "data": { // The instance data } } Separate details into metadata and data sections
- 91. { "detail": { "metadata": { “version”: ”1.2”, “created_at”: ”2023-08-29T12:10:21Z”, “event_id”: ”abc-xyz”, “trace_id”: ”12c-x89”, “domain”: “customers", “subdomain”: “accounts", “service": “registration", “name”: ”account_created” }, "data": { } } } metadata can also carry- TTL Tokens Callback URL etc.
- 92. { "detail": { "metadata": { }, "data": { “account_number”: ”123-456”, “firstname”: ”Joe”, “lastname”: “Bloke", “email": “[email protected]", “dob": “10121999" } } } data section carries the business data.
- 93. For clarity & to control event flow… classify the events.
- 94. Common event classifications Event categories Event types Domain events Operational events Local or internal events State transfer events Cloud provider events
- 95. Common event classifications Event categories Event types Domain events Operational events Local or internal events State transfer events Cloud provider events Command Query Request Data Status Response
- 96. { "detail": { "metadata": { “version”: ”1.2”, “created_at”: ”2023-08-29T12:10:21Z”, “event_id”: ”abc-xyz”, “trace_id”: ”12c-x89”, “domain”: “customers", “subdomain”: “accounts", “service": “registration", “category": “domain_event", “type": “data", “name”: ”account_created” }, "data": { } } } metadata carrying event classification details
- 97. Event notification Event-carried state transfer Domain events Short and brief info URL to fetch details Claim-Check Pattern State change snapshots Carries more details
- 98. Internal events External events Domain events Internal to a context boundary Versioning not a must Shared between bounded contexts Must be versioned
- 99. EDA Patterns
- 100. Service choreography is a coordinated sequence of actions across multiple microservices to accomplish a business process.
- 101. Orchestration is an automated and instructed coordination of several services and resources by an orchestrator to accomplish a business process.
- 102. To protect domain model from invading events… build anti-corruption layers (ACL).
- 103. Collaboration type Customer-supplier Separate ways Cooperation Partnership Shared kernel Conformist Anticorruption layer Open-host service Patterns
- 104. ACL is an integration pattern between two bounded contexts and acts as a translation layer to map data between two systems to protect their data models.
- 105. ACL is an integration pattern between two bounded contexts and acts as a translation layer to map data between two systems to protect their data models. Prevent. Protect. Upstream Supplier Bounded Context Downstream Consumer Bounded Context Data ACL
- 106. If a bounded context conforms to a mess, it risks becoming a mess itself. - Learning Domain-Driven Design
- 107. Customers Rewards 3rd Party SaaS Payments OHS ACL ACL ACL Event Broker Dedicated ACL for the SaaS ACL to protect Orders BC from Payments BC Upstream: Payments Downstream: Orders Async Webhook Domain events emitted as CloudEvents for external consumers Upstream: Payments Downstream: Orders Sync API call Orders BC conforms to Payments BC Orders Bounded Context
- 108. To regulate event exodus and invasion… employ a Gatekeeper event bus.
- 109. A gatekeeper event bus is an event broker that acts as the guarded event gate of a context boundary.
- 110. Every API has a contract, protocol, auth, quota, etc. But how do you apply these to domain events as they flow into and out of your bounded context?
- 111. A gatekeeper event bus is an event broker that acts as the guarded event gate of a context boundary. Guard. Control. Bounded Context Bounded Context Enterprise Event Broker
- 112. User payments bounded context Authorization Refunds Capture Service status Pay by link Payment authorized Payment declined Payment captured Payment refunded Link emailed Link clicked Healthy Unhealthy Finance domain Checkout bounded context Third-party SaaS
- 113. User payments bounded context Authorization Refunds Capture Service status Pay by link Payment authorized Payment declined Payment captured Payment refunded Link emailed Link clicked Healthy Unhealthy Finance domain Checkout bounded context Third-party SaaS Domain events Cross-account event sharing HTTP target
- 114. User payments bounded context Authorization Refunds Capture Service status Pay by link Payment authorized Payment declined Payment captured Payment refunded Link emailed Link clicked Healthy Unhealthy Finance domain Checkout bounded context Third-party SaaS Domain events Cross account event sharing HTTP target
- 115. User payments bounded context Authorization Refunds Capture Service status Pay by link Payment authorized Payment declined Payment captured Payment refunded Link emailed Link clicked Healthy Unhealthy Finance domain Checkout bounded context Third-party SaaS Domain events Cross-account event sharing HTTP target Gatekeeper event bus
- 116. To not loose events and the history… practise event sourcing.
- 117. Event Sourcing is a way of capturing and persisting the changes happening in a system as a sequence of events. PK SK EventID FirstName LastName Address Activity 100-255-8730 2023-04- 05T08:47: 30.718Z Hru343t5-jvc Joe Bloke 99, Edge Lane, London UPDATED 100-735-6729 2023-01- 15T02:37: 20.545Z lgojk834sd3- r454 Biz Raj 12A, Top Street, Mumbai DELETED 100-255-8730 2022-06- 15T18:57: 43.148Z Zxjfie294hfdkd9e 7n Joe Bloke 15, Nice Road, Cardiff CREATED 100-735-6729 2009-11- 29T20:49: 40.003Z skdj834sd3-j3ns Biz Raj 12A, Top Street, Mumbai CREATED
- 118. Bounded Context Level Domain Level Centralized Audit Service User Payments Event Store Event Broker Event Sourcing Service Bounded Contexts Event Store
- 119. Event Broker Cloud Region 3 Account X Event Sourcing Service Cloud Region 1 Account A Account B Cloud Region 2 Account C Cloud Region 4 Account D
- 120. Key Takeaways
- 121. View inter-bounded context communications as contractual agreements. Establish event contracts at the same level as API contracts. EDA isn’t all perfect, but when done properly, it can serve as a catalyst for engineering growth. Business clarity promotes engineering purity. Decomposing the business domain is the first step towards EDA. Modularity is essential for an evolvable EDA. It enables loose coupling and encourages team autonomy. Employ proven industry patterns and practices to safeguard domain models and prevent unauthorized event intrusions.
- 122. Distributed systems are essential for meeting the needs of modern consumers, and EDA plays a crucial role in achieving this. By applying systems thinking and Domain-Driven Design, we can navigate the complexities of EDA through ownership boundaries, communication contracts, collaborative efforts, along with established engineering principles and patterns.
- 123. The Saga Continues…!
- 124. sheen-brisals sheenbrisals sbrisals.medium.com #TheServerlessBook #TheSpeakerBook Architect at Sky AWS Serverless Hero Team Topologies Advocate Sheen Brisals Thank You! leanpub.com/TheSpeakerBook