On Software Architecture Decisions, Evolution and Engineering
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.
blatherings on software…
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.
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.
I have a personal expense tracking app that for the last few months I’d been working to migrate away from MVC towards more modern client apps whilst reusing the backend code and logic.
A few weeks ago I came across this Mars Rover programming challenge/kata and being a bit of a space buff, I thought I will take a crack at it.
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.
Many articles talk about the what of this style but in my view, not enough talk about the how. In this post, I am going to try and show one way to actually structure the solution to be more in line with the hexagonal ports and adapters style.