Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Design principles for an Event Driven Architect...

Luis GC
November 22, 2019

Design principles for an Event Driven Architecture in an Event Driven World

According to Wikipedia, an Event-driven Architecture, is a software architecture pattern that promotes the production, detection, consumption of, and reaction to events.

There is a perfect pairing between microservice-based architectures, Domain Driven Design (DDD) and event-driven architectures. In this conference we will review what design principles are the catalyst for this symbiosis as well as practical examples in different areas including governance. Many business use cases can be articulated on top of these principles, abstracting them from both complexity and variability in the technological stack.

As a good part of the audience will already be dealing with events and microservices, we will also explain other key concepts:

* Designing a future-proof event taxonomy.
* Strategies for event enrichment, starting with the definition of that concept.
* Managing correlation or inference of events.
* Benefits from an event schema registry using for example Apache Avro.
* Traceability of events by design.
* Data conciliation patterns, and when to avoid it.

We will also take advantage of the opportunity to discuss about common challenges (and others not that common), frequent mistakes and how to avoid or mitigate them.

To conclude, we will explain some use cases that we are solving superbly based on real-time events: Communications, Order Management, Business Activity Monitoring (BAM), KYC, GDPR, ...

Luis GC

November 22, 2019
Tweet

More Decks by Luis GC

Other Decks in Technology

Transcript

  1. Design principles for an event driven architecture Commit Conf 2019

    Luis García & Pablo Ruiz Madrid, November 2019
  2. Commercial Banking Retail Banking Why we are here 2 Luis

    García Castro @luiyo Pablo Ruiz Subira @prsubi
  3. Introduction 3 There is a perfect pairing between microservice-based architectures,

    Domain Driven Design (DDD) and event-driven architectures
  4. 4

  5. Event Taxonomy 5 Meaning Driven Business Domain Raw Purpose Driven

    Technical Native Standardized Atomic raw domain Derived (*) business
  6. Taxonomy at microservice level 6 (*) each bus represents one

    specific topic in the Event Bus Domain API BB viewed from the outside Business Technical API Storage Bus Connector CORE Raw Domain Building Block internals Business Technical
  7. Standard language 7 API Call API Call Ubiquitous Language Ubiquitous

    Language Ubiquitous Language Standard Language
  8. Reference Data 9 Building Block A Building Block B Master

    Reference Data Building Block C Datalake
  9. Coupling (loose) 10 Product A transaction received Fraud Engine transaction

    received Fraud Alert!! Communications transaction received Contact customer!! Channel Gateway Contact customer!!
  10. Correlation & Inference 11 Domain A Event A Domain B

    Domain C Event B Domain A Event A Domain B Domain C A & B A & NOT B
  11. Traceability & Lineage 12 Domain A Event Id: 1 TraceID:

    1 Domain B Domain C Event Id: 2 TraceID: 1 Event Id: 3 TraceID: 1 Event Id: 4 TraceID: 1 Domain D Event Id: 5 TraceID: 5
  12. Aggregation / enrichment 13 Domain A Domain B Domain C

    Name: Peter Surname: Parker Job: Photographer Name: Peter Surname: Parker Alias: Spiderman Domain D Name: Peter Surname: Parker
  13. Orchestration 14 Orchestrator Generate Monthly Extract Product A Product B

    Document Mgm Product A movements Product B movements Statement request with Product A&B movements
  14. Choreography 15 Product A transaction received Category Service transaction received

    transaction categorized Customer Reporting transaction received transaction categorized
  15. Privacy / Data Segregation 17 Producer Clear Message <encoded message>

    Clear Message Producer Consumer Name: Clark Surname Kent Income: 1234.00 Name: Clark Surname Kent Income: 1234.00 Other Consumer Name: **** Surname ***** Income: 1234.00 <encoded message> Consumer Other Consumer <encoded message>
  16. Example 21 Change mobile phone number bus storage API Person

    Core raw CDC domain Risk Comm technical Contact hst gateway technical Auth Mobile phone number changed domain partner business x2 technical
  17. Example 22 Change mobile phone number bus storage API Person

    Core raw CDC domain Risk Comm technical Contact hst gateway technical Auth Mobile phone number changed domain partner business x2 1 Explicitly 1. Choreography 2. NOT reconciliation 3. NOT event enrichment 4. Correlation 5. Orchestration Everywhere: • Event taxonomy • Strong cohesion • Loose coupling • Lineage and traceability 2 3 4 technical 5
  18. How EDA impacts a microservice based architecture 23 Feature EDA

    impact Loosely coupled Location transparency Strong cohesion Organized around business capabilities Each service is independently deployable Highly maintainable – Easy to maintain Highly testable – Easy to test Each service is as simple as possible Data Management Transaction Management