Apparently this needs pointing out but there's more than async/await out there. Sometimes what you want is a simple event loop. Here illustrated in the Rust ecosystem.
Or how it's possible to expose an object-oriented like API for a data oriented framework without sacrificing on performances.
Didn't know this kind of architectural pattern had a name. Interesting. I wouldn't recommend it in any context though, but one more metaphor to reason with.
Definitely a handy catalog for designing distributed systems.
A bit of an unusual view about cohesion. The approach is interesting though.
Interesting food for thought. It's important to also approach domain models based on their workflows and events, not just their static relationship graphs.
A good post covering the feature flags concept and the different type of toggles you might have in a project.
Interesting architectural proposal for highly portable C++ based libraries.
Looks like a good set of tips of get more DDD practices in place without the badly understood vocabulary which usually comes with it.
A good reminder of why you often don't want to follow an architecture pattern to the letter. They should be considered like guidelines and depending on your technical context you should properly balance the costs. Here is an example with the Ports and Adapters pattern in the context of an ASP.NET application.
Nice post about pros and cons of ECS architectures.
Interesting piece... why talking about microservices generally leads nowhere. This is a too loosely defined term and we're often confusing means and ends.
Nice little paper I overlooked. I agree with it obviously. More tests are not a free pass to let complexity go wild. Architecture and design concerns are still very important even if you TDD properly.
I'm not a huge fan microservice based architectures. That said the parallel done there is interesting and a good reminder that the "write programs that do one thing and do it well" quote is incomplete.
Yet another long piece in this interesting and in depth conversation about Bluesky. The fact that it stays civil is called out explicitly and this is appreciated.
We're still struggling about how to modularize our code. Sometimes we should go back to the basics, this paper by Parnas from 1972 basically gave us the code insights needs to modularize programs properly.
A good reminder that genericity can help fight against the rigidity one can accumulate using purely object oriented couplings... but it comes at a price in terms of complexity.
Good explanation on how the agile movement scaled down about design over time in its literature. It's probably its biggest failure. The good thing is that the pendulum is starting to swing in the other direction a bit (that's probably why Beck is now working on a book series on software design).
Definitely this. Our cognitive capacity is limited, we'd better not deplete it due to complexity before we even reach the core of the problem at hand.
I tend to side on the "boring tech" side, but indeed this is a good reminder that what we want is finding the right balance.