event storming & event sourcing with lagom
TRANSCRIPT
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
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
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