Nice to see an example combing gaming and typical business domains.. really useful for turn-based or timer-based online games. I'll certainly get back to this example when implementing more complex processes in my codebase.
that is a nice, polite, and well-tempered talk. all what is said is holy truth. some minor problems is omitted though. Like, in a real world, if you monolith app is not just a handful of tables, capturing db transaction log and mapping it to events might be non-trivail task and imagine you have an aggregate spilled over 10 tables with several levels of depth and you need track each individual db record change to the aggregate "root" - that is anything but easy and requires some stateful processing (dataflows) on the edge of tx log capture. So the only practical approach in such cases is a transacional outbox, but there (depending on the monolith size and health) you might battle the issue as to where to place that logic. In a typical layered application esp those based on ORM tech (like hibernate etc), usually it's quite difficult to find an appropriate place where you might add the logic of producing the outbox event and which has all necessary data readily available. and fetching the additional data might trigger very surprising consequences in app performance profile or even behaviour. but all this pales in comparison with the struggles a typical "SQL monolith fits fine into 99.9% of my requirements" team would face on the challenge of identifying what is event and why it exists. many of them start mapping events as mere commands/results to their respective service methods, and that is a pawed way to failure ...
My key take aways: * tell those devs who want to use kotlin to go f- themselves and just keep the good ol' monolith Now, seriously: have we all gone completely insane as an industry? Say it with me: you👏don't👏need👏a👏network👏to👏set👏boundaries. Do it in your code. Be diligent and force devs to respect contexts. One stateless hosting unit (modular monolith) + a relational database solves 99.9% of all requirements you will ever encounter. Including scaling (just scale horizontally). The RDB is becoming the bottleneck? Do some sharding. Really guys, we don't need too much complexity to do our job properly.
@juancruz-theflock I hope that is also what exactly you tell you mgrs when they come with a request "for the next big customer beta", and you realise that the only way to achieve this is to temporarily forget about "context boundaries" - I mean you say them "go f- themselves". And you colleagues do the same, and then your mgrs proxy it to their mgrs w/o any "information hiding".
Jumping between the two stories (café and game thing) is unnecessarily confusing. Just pick one, ideally, the one based on your experience instead of the toy example.
Poor enforcement of modularity is a really bad argument against a monolith, same with changes to unrelated code. If you have a proper moodular monolith build, each module communicates through a queue or client to each other and do not share code. And enforcing it is no harder than writing some architecture tests to check for invalid imports from outside a module. Seems more like you had experience with bad module boundaries than a monoloth. You can have the exact same issue with microservices sharing common code.
Nice to see an example combing gaming and typical business domains.. really useful for turn-based or timer-based online games. I'll certainly get back to this example when implementing more complex processes in my codebase.
interesting presentation.
that is a nice, polite, and well-tempered talk. all what is said is holy truth. some minor problems is omitted though. Like, in a real world, if you monolith app is not just a handful of tables, capturing db transaction log and mapping it to events might be non-trivail task and imagine you have an aggregate spilled over 10 tables with several levels of depth and you need track each individual db record change to the aggregate "root" - that is anything but easy and requires some stateful processing (dataflows) on the edge of tx log capture. So the only practical approach in such cases is a transacional outbox, but there (depending on the monolith size and health) you might battle the issue as to where to place that logic. In a typical layered application esp those based on ORM tech (like hibernate etc), usually it's quite difficult to find an appropriate place where you might add the logic of producing the outbox event and which has all necessary data readily available. and fetching the additional data might trigger very surprising consequences in app performance profile or even behaviour. but all this pales in comparison with the struggles a typical "SQL monolith fits fine into 99.9% of my requirements" team would face on the challenge of identifying what is event and why it exists. many of them start mapping events as mere commands/results to their respective service methods, and that is a pawed way to failure ...
My key take aways:
* tell those devs who want to use kotlin to go f- themselves and just keep the good ol' monolith
Now, seriously: have we all gone completely insane as an industry? Say it with me: you👏don't👏need👏a👏network👏to👏set👏boundaries. Do it in your code. Be diligent and force devs to respect contexts.
One stateless hosting unit (modular monolith) + a relational database solves 99.9% of all requirements you will ever encounter. Including scaling (just scale horizontally). The RDB is becoming the bottleneck? Do some sharding.
Really guys, we don't need too much complexity to do our job properly.
I like this quote "Really guys, we don't need too much complexity to do our job properly."
@juancruz-theflock I hope that is also what exactly you tell you mgrs when they come with a request "for the next big customer beta", and you realise that the only way to achieve this is to temporarily forget about "context boundaries" - I mean you say them "go f- themselves". And you colleagues do the same, and then your mgrs proxy it to their mgrs w/o any "information hiding".
Jumping between the two stories (café and game thing) is unnecessarily confusing. Just pick one, ideally, the one based on your experience instead of the toy example.
Poor enforcement of modularity is a really bad argument against a monolith, same with changes to unrelated code. If you have a proper moodular monolith build, each module communicates through a queue or client to each other and do not share code. And enforcing it is no harder than writing some architecture tests to check for invalid imports from outside a module.
Seems more like you had experience with bad module boundaries than a monoloth. You can have the exact same issue with microservices sharing common code.