Event Driven Architecture

Overview

The scope of our WG is to provide viewpoints and how-to guides for banks, vendors, or others to do their own mapping of service domains to events.

An event-driven architecture (EDA) when applied to a system design allows avoiding bottlenecks of synchronous processing, evolve from batch- to real-time processing, allowing the flow of messages through the system faster, and guaranteeing the decoupling between service domains proposed by BIAN. It has been applied in the industry for decades, and today it is quintessential for the modernization of the Core and facilitates the development of modular banking architecture, based on microservices and cloud.

Event-driven reverberates and can mean many different things. As a baseline we take into consideration the primitives as suggested by the author Martin Fowler, it’s identified when found an architecture adopting a combination of these four patterns:

• “Event notification: components communicating via events

• Event-based State Transfer: allowing components to access data without calling the source.

• Event Sourcing: using an event log as the primary record for a system

• CQRS (command-query responsibility segregation): having a separate component for updating a store from any readers of the store”

Targets

• Semantic mappings of the service operation to these events

• Meta-model design in archimate to represent a generic pattern for how it works and relates to the service definition

• Set of use cases identifying the use of the relevant Exchange Types for event-driven

• Validate in an exercise of practical implementation of the set of use cases with the support of the EDA service definition meta-model