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!
Since my first post on agentic refactoring and having attended O’Reilly Coding With AI seminar, I have learnt about a couple of techniques (more like still learning to get good at them), that have improved the results I have had with agentic coding somewhat
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
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.
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
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.
The central idea around Blazor auth is for the UI system to be able to query the authentication state of the user and render different views. Blazor uses AuthenticationStateProvider to query this auth state via the AuthorizeView component.
Given the fact that there is no shortage of SPA frameworks and libraries like Angular, React, Vue, Knockout ad inifitum, for building the new frontend app for my app, I decided to go with Blazor.
Artineering 