Event-Driven Microservices, the Sense, the Non-sense and a Way Forward - Allard Buijze

(https://www.youtube.com/watch?v=jrbWIS7BH70)

Why microservices

monolith that is well-structured, can scale as well

What goes in one service?

What goes in another?

order

customer

product

inventory

Are you micro-pile-of-shit?

- redeploy multiple services at one

- strong dependencies on other service before you can do something

"just go up, and then go right"

anti-modularity forces

suit & tie telling you "the deadline shifted"

technical debt

"""

it's all about discipline

if you can't wax a car, forget about karate

If you can't build a monolith, forget about microservices

"""

there is a journey towards microservices

1) build monolith

2) compnents

3) split off services => non-functional requirements

assume components are not on the same deployment

inverted

"if all you have is a hammer, everything looks like a nail"

event patterns

event notification: "something changed"

event-carried state transfer: "this changed"

event sourcing: everything becomes an event

duplicate logic

item is ordered if added, not removed, then ordered

event: explain something happened

command: intent to change something

queries: need for information

=> event notification

!= just save all the events

event handling

Event sourcing check:

throw away everything, except your eventstore

storage is cheap

everything is complex at first

forget about state, think about behavior

"if all you have is a hammer, everything looks like a nail"

:) can I do this one change?

:( "give me all orders above 100$"

:) can I do this one change?

:) "give me all orders above 100$"

events -> contracts with unknown services

consumer driven contracts

within context, want details

across borders, high level

assign services to bounded context

anti corruption layer

use them as explicitly as events

monolith first

disciplined modules

split off services