EVENT STORMING& EVENT SOURCINGWITH LAGOM

TYPO3 CAMP

BERLIN

27.06.2017

GERNOT SCHULMEISTER

Lives in Mönchengladbach

Developes websites with TYPO3 and Angular

Works for TeamWFP

Has a migration background and comes from

Southeast-Europe (Austria)

Likes operative CMS evaluations, Data science,

Software Architecture, Meetups, Bar camps

facebook.com/gernot.schulmeister

twitter.com/mistakanista1

SEITE 2

SCHEDULE

Motivation

Event Storming

Microservice Frameworks

Event Sourcing - CQRS

Message Bus

MOTIVATION

Event Storming seems to be a nice approach to plan

and

cut applications into domains

Event sourcing is planned for TYPO3

Microservice Frameworks have nice concepts

Headless CMS become more important

Checking out if the approach could be useful for

TYPO3

SEITE 4

EVENT STORMING

Workshop method to create a deep understanding of a

software domain

Part of domain driven design, business experts come

together with developers to explore the context of a

software problem to solve

Make sure to solve the right problem

Find the correct starting point and save iterations

Include more stakeholders

Avoid risks of strange, designed business processes

Realise know how lacks & deficits early

SEITE 5

IF WE DON’T DO IT

We solve a problem with software that would be better solved by

organisation and cause avoidable costs

High refactoring costs if the domains have cut wrong especially for

microservices

We think we understand what is required and realize later that we

did not know enough, which costs expensive iterations

We ignore the contribution of some stakeholders because there were

too many at the beginning and realize later that their point of view

changes the required functionality

SEITE 6

HOW IT WORKS

Brainstorming to find business events of your domain

Formulate them in the past and write them on post its

Examples for a shop: Order received, invoice created, payment

cleared, goods delivered

Derive from these events, processes, data and user interfaces

Event storming starts at the end not at the customer

requirements

Result is domain knowledge which might be the basis of other

methods, like user stories

SEITE 7

WHAT IS NEEDED

A room without chairs and tables with a big

empty space on the wall

Fasten a roll of paper on the wall, where post

its can be fixed

A flipchart to explain the meaning of the post

its

SEITE 8

Meaning Post it size Post it color

Business Small Orange

User Small Yellow

Aggregat Large Yellow

Command Small Blue

External

system

Large Pink

Read model Small Green

User interface Large White

Policy Small Violet

FLIPCHART WITH LEGEND

SEITE 9

PROCESS

Start with the orange post its to write business events

Bring them in the right order on the timeline

People will automatically start to discuss

cause – effect relations

these discussions have the biggest value

Refinement: explain the meaning, remove duplicates

Extract the roots of the events: User actions, external systems, time, other domain

events

Explain other elements of the model as soon as the appear

Mark risks with the WTF post its

SEITE 10

RESORT AND RESULTS

Take the post its from the timeline and group them around the

aggregates

This makes the following connections clear:

Which user causes which command

Which commands effect which aggregates or external systems

and cause which changes

Which aggregates or external systems cause under which commands which events

Which events start which policies and from which events which read models are

generated

Which policies call which new commands

SEITE 11

NEXT STEPS

Bounded context are grouped around aggregates like purchase, stocks, sale, invoices

Further refinement, design and realisation

Aggregates and policies are basis for the design of microservices with specific

responsibilities and tasks

Good maintainable structure of the system with less refactoring

User stories, if you see a user triggering a command

Read models describe information for the user to make a decision, interfaces are

placeholders for the required presentation of this information

Basis for user experience and user centered design

SEITE 12

MICROSERVICE FRAMEWORK

No definition or wiki entry so far

System to set up an application consisting of microservices

Unified communication between the services

Easy development setup which allows to work on several

services at the same time

Opinionated, takes decisions for the developer with a

standard setup

Scalable and resilient each service as cluster with a variable

number of nodes

Examples: Spring Boot, Dropwizard

SEITE 13

LAGOM

just right, swedish for the scandinavian live style of no extremes

Developed with Java 8 by lightbend, open source

Asynchrone nature

Thread per request model, but only few threads are used

Hardly simple method request

Default return value is a “CompletionStage” which can take on

callbacks

Immutable, value or data objects: functional programming

No changeable, shared data, no blocking requests

SEITE 14

EVENT SOURCING - CQRS

SEITE 15

Event sourcing used for persistence, every change is a

database entry like a commit, saves all events

CQRS: Command Query Responsability segregation

Reading Object in the storage (RAM) for

representation in the user interface

Big advantage if database has to scale on more

than one server

Lagom persistence: cluster sharding

dynamically, variable number of nodes

at runtime

CASSANDRA

SEITE 16

Used as default NoSQL database

Distributed database administration system with high scalability and fail safety

Key value store with CQL (Cassandra Query language) similar to SQL

Columned based database, the partitioning is line based

Fault tolerance: no single point of failure since data is replicated to several nodes

No master node, each node can handle any request

Tuneable level of consistency from „writes never fail“ to „block all replicas to be

readable“

Hadoop integration with map reduce support

No row level consistency (inserts in the same row in different columns at the same

time in different replicas)

KAFKA AS MESSAGE BUS

Alternative for the pull approach to deliver data when required

Push: changes in a service cause domain events which are published via a message

bus to other services, which have registered for this events

The sent messages are then stored and handled locally in the services that have

registered for them

Message broker to handle data streams with high throughput and low latency

Runs obligatory in a cluster with a Zookeeper quorum

Variable number of topics handle messages that are published by producer and read

by consumer

Topics consist of partitions which are distributed to the brokers for load balancing

SEITE 17

DEVELOPING WITH LAGOM

Comes with a Maven Plugin (Dependency Management like

Composer)

Create a new project with a Maven Archetype

Run the project with mvn lagom:runAll

Hot reloading: automatic compilation after code changes

without new server start

There are some demo projects to get started

Impresses by its architecture and capability

Improvements regarding monitoring, exchange of standard

components and integration of orchestration platforms like

Kubernetes are possibleSEITE 18

CONCLUSION

Event storming:

Brings developer with domain experts together

Remarkable event which is often referred to later

I think it is worth to try it out

Lagom:

Not necessary for TYPO3 developer but nice architecture and concepts

SEITE 19