blatherings on software…
My goal with this post is to propose a model for structuring .NET monoliths in a modular fashion that both keeps distribution complexity low whilst at the same time keeping options for distribution in the future, open!
I have been reading, hearing a lot about how AI/vibe coding will make software engineers obsolete and that agentic coding is like magic…so I decided to give agentic refactoring a shot
A practice in domain (re)modeling using my pet project, guided by strategic and tactical DDD patterns.
In this post I will try to use simplified Systems Thinking modelling language to put technical debt in the larger organisational context with the hope that it will make some sense to everyone.
Deliberate and thoughtful architectural decisions that solve real business problems and mitigate enough of the real risks, is the RIGHT and the MIDDLE PATH way to go.
There are many posts and articles that expound the virtues of paying back the tech debt and philosophise at great lengths about the various design patterns that can improve the design of the code. In this post I’d like to tackle the more pragmatic and real life aspects around tech debt from my perspective.
In this post I will share some of the TDD heuristics that I have found useful on when you should use mocking to verify interactions and when should you resort to state verification.
Artineering 