Domain Event Driven Architecture Stefan Norberg, Head of - - PowerPoint PPT Presentation

▶
domain event driven architecture
SMART_READER_LITE
LIVE PREVIEW

Domain Event Driven Architecture Stefan Norberg, Head of - - PowerPoint PPT Presentation

Sep 04, 2022 275 likes •943 views

Domain Event Driven Architecture Stefan Norberg, Head of Architecture at Unibet.com twitter: @stnor email: stefan.norberg@unibet.com blog: http://stnor.wordpress.com @stnor 17 years as an IT professional Has worked with most aspects

slide-1
SLIDE 1

Domain Event Driven Architecture

Stefan Norberg, Head of Architecture at Unibet.com

twitter: @stnor email: stefan.norberg@unibet.com blog: http://stnor.wordpress.com

slide-2
SLIDE 2

@stnor

  • 17 years as an IT professional
  • Has worked with most aspects of IT
  • Operations & infrastructure
  • IT security
  • Systems development
  • Software architecture
  • Enterprise architecture
  • Head of Architecture at Unibet
slide-3
SLIDE 3

Agenda

  • Basics and EDA intro
  • The SOA problem
  • How Domain EDA completes SOA
  • Implementation notes from Unibet
  • What to tell your manager
slide-4
SLIDE 4

The three styles of interaction

Type of interaction Initiator Participants Time-driven Time The specified systems Request-driven Client Client and Server Event-driven Event Open-ended

slide-5
SLIDE 5

Time driven

Fruit system

run inventory check every 60 mins

slide-6
SLIDE 6

Request driven

Tarzan Fruit system

Me want three bananas!

slide-7
SLIDE 7

Event driven

“Tarzan took three bananas” “Fruit system is low on bananas”

Fruit system

slide-8
SLIDE 8

5 Principles of EDA

  • “Real-time” events as they happen at the

producer

  • Push notifications
  • One-way “fire-and-forget”
  • Immediate action at the consumers
  • Informational (“someone logged in”), not

commands (“audit this”)

slide-9
SLIDE 9

Typical EDA architecture

system system system Event Bus

Event Producers Event Transport

system system system

Event Consumers

slide-10
SLIDE 10

Main benefits of EDA

  • Supports the business demands for better

service (no batch, less waiting)

  • No point-to-point integrations (fire &

forget)

  • Enables high performance, highly scalable

systems

slide-11
SLIDE 11

The birth of a system

Customer Shop Inventory

slide-12
SLIDE 12

The monolith

Payment Customer Reporting Inventory Shop Newsletter

slide-13
SLIDE 13

SOA architecture #1

Shop Payment Newsletter Inventory Customer DB Reporting

Divide the problem domains into separate systems

slide-14
SLIDE 14

SOA architecture #1

Shop Payment Newsletter Inventory Customer DB Reporting

A lot of point to point integration...

slide-15
SLIDE 15

SOA architecture #2

Shop Payment Newsletter Service Bus Inventory Customer DB Reporting

Monolith?

slide-16
SLIDE 16

Let’s add fraud checks

Shop Payment Newsletter Service Bus Inventory Customer DB Reporting

fraud fraud

slide-17
SLIDE 17

Let’s add a loyalty system

Shop Payment Newsletter Service Bus Inventory Customer DB Reporting Loyalty

fraud fraud

slide-18
SLIDE 18

Integration ripple effect

Shop Payment Newsletter Service Bus Inventory Customer DB Reporting Loyalty

fraud fraud

slide-19
SLIDE 19

Problem summary

  • SOA is all about dividing domain logic into

separate systems and exposing it as services

  • Some domain logic will, by its very nature,

be spread out over many systems

  • The result is domain pollution and bloat in

the SOA systems

slide-20
SLIDE 20

“It's really become clear to me in the last couple

  • f years that we need a new building block and

that is the Domain Events”

  • - Eric Evans, QCon 2009
slide-21
SLIDE 21

Domain Events and SOA

  • A Domain Event is something that

happened that the domain expert cares about

  • A SOA system’s primary focus should be
  • n the domain and domain logic
slide-22
SLIDE 22

Domain EDA

  • By exposing relevant Domain Events on a

shared event bus we can isolate cross cutting functions to separate systems

slide-23
SLIDE 23

Domain EDA + SOA

Shop Payment Newsletter Inventory Customer Reporting Loyalty Event Bus

slide-24
SLIDE 24

Domain EDA + SOA

Shop Payment Newsletter Inventory Customer Reporting Loyalty Event Bus BAM Fraud

slide-25
SLIDE 25

“You complete me”

SOA Domain EDA

slide-26
SLIDE 26

Example how Domain EDA decouples

slide-27
SLIDE 27

Trading system model Reporting system model

Coupled integration

slide-28
SLIDE 28

Trading system model v2 Reporting system model

Coupled integration

slide-29
SLIDE 29

Trading system model Reporting system model

domain events

I’m interested in buy, sell and market status events

subscribe

Domain EDA integration

slide-30
SLIDE 30

Trading system model v2 Reporting system model

domain events

I’m interested in buy, sell and market status events

subscribe

Domain EDA integration

slide-31
SLIDE 31
  • “So what? I can do that with SOA...”
  • “Yes, but can you do THIS?” (drumroll)
slide-32
SLIDE 32

Trading system model v2 Reporting system model

domain events

I’m interested in buy, sell and market status events

subscribe

Trading system NG model

domain events

Domain EDA integration

slide-33
SLIDE 33

Trading system model v2 Reporting system model

I’m interested in buy, sell and market status events

subscribe

Trading system NG model

domain events

Domain EDA integration

slide-34
SLIDE 34

Example how EDA scales

slide-35
SLIDE 35

Traditional SOA scalability issue

Order processing

200 tx/s

slide-36
SLIDE 36

Traditional SOA scalability issue

Order processing Loyalty system

request/response

200 tx/s

slide-37
SLIDE 37

Traditional SOA scalability issue

Order processing Loyalty system

200 tx/s 100 tx/s

request/response

slide-38
SLIDE 38

SOA: Weakest link dictates the peak throughput

  • f the system

Order processing Loyalty system

100 tx/s 100 tx/s

request/response

slide-39
SLIDE 39

Order processing Loyalty system

200 tx/s 100 tx/s

EDA: Weakest link dictates the sustained throughput

  • f the system

event

slide-40
SLIDE 40

Implementation notes from Unibet

hans.hall@unibet.com

slide-41
SLIDE 41

MQ considerations

  • Ordering
  • Durability
  • Performance
  • Once and only once delivery
slide-42
SLIDE 42

Our requirements

  • 1000 messages / second sustained
  • Guaranteed delivery
  • Easy to use client
slide-43
SLIDE 43

Brokers tested

  • Lots of brokers tested
  • ActiveMQ, OpenMQ, HornetQ,

Websphere, Fiorano, RabbitMQ, QPID

  • Second round
  • ActiveMQ, OpenMQ and RabbitMQ
  • Finally went for ActiveMQ - fitted our

requirements/use case the best

slide-44
SLIDE 44

Testing brokers

  • Killing brokers
  • Flow control
  • Slow consumers
  • Durable / non-durable
  • Small configuration change can have huge

impact on throughput

slide-45
SLIDE 45

Payload considerations

slide-46
SLIDE 46

The smorgasbord

Name Standardized Schema support Binary Easy to use X-platform Std API ASN.1 CSV XML JSON Java serialization Hessian Protocol Buffers BSON Yes Yes Yes No Yes No Partial No No No? Yes No Yes Yes No Yes Yes

DOM, SAX, XQUERY, XPATH

Yes No No Yes Yes No No Partial Yes Yes No No No Partial Yes Yes Yes No No Yes Yes Yes Yes No No No Yes Yes Yes No

slide-47
SLIDE 47

Domain events need schema support

Name Standardized Schema support Binary Easy to use X-platform Std API ASN.1 CSV XML JSON Java serialization Hessian Protocol Buffers BSON Yes Yes Yes No Yes No Partial No No No? Yes No Yes Yes No Yes Yes

DOM, SAX, XQUERY, XPATH

Yes No No Yes Yes No No Partial Yes Yes No No No Partial Yes Yes Yes No No Yes Yes Yes Yes No No No Yes Yes Yes No

slide-48
SLIDE 48

+ Efficient, x-platform and easy to use

Name Standardized Schema support Binary Easy to use X-platform Std API ASN.1 XML Protocol Buffers Yes Yes No No Yes No Yes Yes No Yes Yes

DOM, SAX, XQUERY, XPATH

No Yes Yes Yes Yes No

slide-49
SLIDE 49

Protocol Buffers

  • Flexible, efficient, automated mechanism for

serializing (binary)

  • Schema support (.proto files)
  • Language neutral
  • Invented and used by Google Open

Sourced in July 2008

slide-50
SLIDE 50

Example

newuserevent.proto:

  • ption java_package = "com.example.foo";

message NewUserEvent { required string name = 1; required int32 id = 2;

  • ptional string email = 3;

enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1;

  • ptional PhoneType type = 2 [default = HOME];

} repeated PhoneNumber phone = 4; }

slide-51
SLIDE 51

Generating Java Source

$ protoc --proto_path=IMPORT_PATH \

  • -java_out=DST_DIR \

path/to/file.proto

IMPORT_PATH specifies a directory in which to look for .proto files when resolving import directives. If the DST_DIR ends in .zip or .jar, the compiler will write the

  • utput to a single ZIP-format archive file with the given name.
slide-52
SLIDE 52

Builders vs messages

NewUserEvent stefan = NewUserEvent.newBuilder() .setId(1337) .setName("Stefan Norberg") .setEmail(“stefan@norberg.org") .addPhone( NewUserEvent.PhoneNumber.newBuilder() .setNumber("+46 70 99 66 547") .setType(NewUserEvent.PhoneType.WORK)) .build();

  • Messages classes are immutable
  • Use builders to construct
slide-53
SLIDE 53

Evolving messages

  • You cannot remove required fields
  • New fields that you add should be optional
  • r repeated
  • New fields should have sensible defaults
  • Prefix deprecated non-required fields with

OBSOLETE_ (convention)

slide-54
SLIDE 54

Sample EDA producer

@Autowired DomainEventPublisher publisher; NewUserEvent stefan = NewUserEvent.newBuilder() .setId(1337) .setName("Stefan Norberg") .setEmail(“stefan@norberg.org") .addPhone( NewUserEvent.PhoneNumber.newBuilder() .setNumber("+46 70 99 66 547") .setType(NewUserEvent.PhoneType.WORK)) .build(); publisher.publish(stefan);

slide-55
SLIDE 55

Sample EDA consumer

public class YourDomainListenerPOJO { public void receive(LoginEvent loginEvent) { // do something } @Durable(clientId=”com.example.foo.bar”) public void receive(NewUserEvent newUserEvent) { // do something } } <import resource=”classpath:spring-domain-events.xml /> <bean id=”domainEventListener” class=”com.foo.YourDomainListenerPOJO”/> <domain-events:subscribe id=”eventSubscriber” subscriber=”domainEventListener”/>

slide-56
SLIDE 56

What to tell your manager

slide-57
SLIDE 57

What to tell your manager

  • SOA+EDA will reduce time-to-market for

new functionality

  • SOA+EDA will enable a layer of high-value

services that have a visible impact on the bottom line of the business

slide-58
SLIDE 58

Game changing value-add

slide-59
SLIDE 59

Complex Event Processing (CEP)

  • 100% Event-driven
  • Receives domain events
  • Performs event correlation using a QL
  • Fires domain events (“findings”)
slide-60
SLIDE 60

CEP Examples

Correlation (CEP)

events events “findings” if there are no Mastercard deposits from France in 5 minutes during business hours, send NoDespositsEvent if there are >30 failed logins using >5 accounts from the same ip within 2 minutes, block the ip for 24 hours if customer with loyalty >= gold and puts goods in shopping cart for more than €200, send VIPShoppingEvent if customer loses €2000 in the casino within 30 minutes and customer != highroller send PotentialHighrollerEvent AND grant €200 casino premium request/response “action”

slide-61
SLIDE 61

Business Process Management (BPM)

  • Business control over definition and

automation of business processes

  • SOA services “orchestration”
  • Processes can/should be started by domain

events

slide-62
SLIDE 62

BPM example

Evaluate Highroller Start Profit > €5000 Manual investigation / decision Set VIP Status Stop Get Customer Info decision? Manager approval Profit > €1000 approved? Stop Stop

PotentialHighrollerEvent Customer System

slide-63
SLIDE 63

Business Activity Monitoring (BAM)

  • Aggregation, analysis, and presentation of real

time information about activities inside

  • rganizations and involving customers and

partners

  • BAM attempts to do for business processing

what network management tools do for network operations

slide-64
SLIDE 64
slide-65
SLIDE 65

The real-time business eco system

Service Oriented Architecture (SOA) Domain Event Driven Architecture (D-EDA)

Correlation (CEP) Processes (BPM) Monitoring (BAM)

Business Value IT enhancements Great business

IT systems

Great architecture

events events events events events request/response request/response

slide-66
SLIDE 66

Thank you!