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!
Last week I attended the O’Reilly “Coding With AI – The End of Software Development As We Know It”…so in this quick post I will share my bullet point takeaways, ideas and lessons from that event
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
In part 1 I talked about the key aspects of my TDD practice from a workflow pov, in this final part I will talk about the more tricky aspects of TDD – scope and design.
Having recently completed several weeks of pairing with a junior engineer on one of my teams, I came away with some reflections on the practice of TDD and its effect on design that I want to share.
I will attempt to define each element of the style a bit and also show some C# code examples to illustrate the points
In this post, I will share my experiences leveraging Domain Driven Design strategies and Team Topologies to reorganise two product engineering teams in the Purchasing domain at Coolblue (one of the largest e-commerce companies in the Netherlands).
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 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.
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
Artineering 