Other things I've learned tonight:
- all those context switches between dozens of projects are a lot more exhausting and mentally draining than you could possibly imagine
- this would have been a lot worse without #golang's strict coding style and formatting conventions
- many projects have a CI pipeline set up, but ignore lots of the brilliant code analysis tools the Go ecosystem provides
- Maybe C++ projects next? Not sure that's a good idea for my mental health 😂
Interesting read on how to approach a problem-solving process: https://jasonmccreary.me/articles/shifty-email-bug/
long, domain-driven-design, php, shoptalk
> Rule: Use Eventual Consistency Outside the Boundary
Been thinking about this "rule" in DDD and when should it be broken or when does it make sense to push for implementing it.
It seems to make a lot of sense with languages that support easy concurrency or an application that has or will scale beyond the scope of just being some website running on a VM with one database... (let's be honest, odds are it ain't happening)
Eventual consistency does add a lot of mental overhead to the developers. It took me probably a solid year of working with such a distributed system to wrap my head around how to design and test.
And then there's the fact that PHP doesn't support concurrency out of the box. So the work around to get domain events working is a message queue/daemon running separate from the web server. That's another failure point for ops.
So would the effort be worth it to sell to a team with only so-so ops experience and zero concurrent programming experience when they could just handle updating the two aggregates in the same request with negligible impact to computing time?
Bonsoir, j'ai fait une tarte à la rhubarbe.
Trying to make #SoftwareDevelopment a better place.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!