Reflections on TDD and Software Design – Part 2
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.
blatherings on software…
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
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.
Recently a planned AWS Aurora database failover/master reboot caused database connection failures in one of our services which caused me to delve deeper into how MySql driver manages connections under the hood.
Monitoring the health of your application in production is a crucial aspect of software development because at any given point in time, you want to be reasonably certain about how your business critical application is performing and you want to be alerted to any problems that might be brewing up in the application before your customers do.
…the whole business process can be divided into smaller asynchronous sub-processes with each one feeding i.e. “piping” its output into the input of the subsequent process(es). At each stage some processing is done for e.g. data enriching, filtering etc and this processing generically is termed as a “filter”.
The way logging and instrumentation in code has traditionally been done is something like the below, say, I want to profile my application service method called “PeriodCloseReportAsync()” that gets called … Continue reading Using DispatchProxy for Centralised Structured Logging in ASP.NET Core
Seeing as micro-service architectures are all the rage these days, I decided to dip into it by building…
In this post I will show one way to mix JWT Token authentication with cookie authentication using ASP.NET Core and send out the JWT in a response cookie.