blatherings on software…
I wanted to reflect on and share my experience and learnings from big picture event storming sessions. Hopefully it will be helpful for others as well, but if there are tips and tricks I am missing please feel free to leave a comment or two
In this final part, I will review the current domain model, explore alternatives and make some model improvements keeping in mind the outcome of the design level event storm. Finally I will end with some DDD takeaways that should be applicable generally
A practice in domain (re)modeling using my pet project, guided by strategic and tactical DDD patterns.
In this post I present some finer grained lessons we’ve learned (a. k. a burn marks) since then having solved some foundational problems that surfaced due to not paying enough attention to the failure modes inherent in EDAs, upfront
We built an event driven system in my team over 2 years ago that sometime back ran into database transaction deadlock problems which puzzled me enough to want to take a deeper look into what happened. This mini-post is a bit of documentation of that investigation.
Recently a planned AWS Aurora database failover/master reboot caused database connection failures in one of our services which caused me to delve deeper into how MySql driver manages connections under the hood.
In this somewhat of a long post, I will go over some of the lessons I and my team learned while building an event driven architecture at work, why did we build it, recommendations and watch-outs for anyone else thinking of doing the same. This is more of a field report from a real life environment so there is a generous helping of pragmatism around architecture and careful and deliberate avoidance of dogma and purism.
Artineering 