The document discusses the design of microservices for autonomy, emphasizing the importance of defining team responsibilities and scaling development. It addresses the transition from imperative to reactive processes using process managers that handle commands and events to facilitate communication between services. Additionally, it outlines methods for keeping track of process states and solving query issues through event publication and subscription.

1. Designing
for Autonomy
Matthias Noback
@matthiasnoback

3. Microservice envy

4. https://leanpub.com/microservices-for-everyone

5. A microservice architecture
can help you...
- Define team responsibilities
- Scale your development team
- Prevent big balls of mud at the code-level
- Scale horizontally

6. The problem is
designing for
autonomy

13. From imperative
To reactive

14. Do this.
Then do that.
Then do something else.
Do this.
When "this has happened", do that.
When "that has happened", do something else.

17. Process managers

19. Add drawing: states, events and new commands

21. Solving the command issue
1. Tell the user you "accepted" their command, continue
processing behind the scenes.
2. Process the first step of the process, then emit an event
about it.
3. Let other services respond to this event and take their
own step, emitting an event about it, and so on.

22. Insight in the process
1. Use process managers to send new commands based on
incoming events.
2. Let the process manager keep track of the current state
of each process.

23. What about queries?

26. "What's the current
state of something-
something?"

27. The current state is the
result of all past events

34. Solving the query issue
1. Services publish their events.
2. Other services subscribe to these events and update their
own state accordingly.
3. They can build up any projection they like. This gives
them the answers they need, without even asking.

38. Thanks!
Questions?