5. @Ramtop
Command
●
A Command is a request for changing the
internal state of the system
●
A Command can “fail” if is not congruent with
the current state of the System
●
Each Command is executed in an atomic
context
6. @Ramtop
Query
●
A query ask for a snapshot of the state
●
Queries typically need different data and
denormalization from domain model. So we separate
the models in CQRS.
●
Queries are eventually consistent with the domain
7. @Ramtop
Values-Entities
●
They represent the state of the domain
●
In functional programming everything is
immutable, so there is no identity
●
To keep state changes we have Algebraic Data
Types
9. @Ramtop
Event
●
Events are the “atoms” of System state change
●
Nothing can change without an event, every
event can change only one entity
● Entity + Event => Entity
10. @Ramtop
Actors
●
More powerful and easy to use concurrency
model than Threads/Locks
●
They communicate asynchronously and
potentially remotely
●
Useful for Bounded Contexts and Services
12. @Ramtop
Antica Pizzeria
●
Real application is about finance products
booking but a pizzeria has a surprising similar
domain
●
We want to do implement the backend for a
ChatBot that will assist booking and enquires
about orders.
13. @Ramtop
Kotlin Syntax
●
No semicolon!
●
String? Is a different type from String
●
myFun{println(it)} is equivalent to
myFun(x -> println(x))
●
val xy is declaring xy immutable
var xy is declaring xy mutable
●
User(“Joe”) is equivalent to Java
new User(“Joe”)