Event Storming is agile method to find the bounded context for a software problem. Lagom is a Java Microservice Framework with Event sourcing and CQRS which uses Cassandra as database and Kafka as message broker.

1. EVENT STORMING
& EVENT SOURCING
WITH LAGOM
TYPO3
CAMP
BERLIN
27.06.2017

2. 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

3. SCHEDULE
 Motivation
 Event Storming
 Microservice Frameworks
 Event Sourcing - CQRS
 Message Bus

4. 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

5. 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

6. 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

7. 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

8. 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

9. FLIPCHART
WITH LEGEND
SEITE 9

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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)

17. 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

18. 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 possible
SEITE 18

19. 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