Rants on Software Design

Is software engineering solved?

I was recently asked this question on LinkedIn.

“I can’t rely on LLMs because they’re not deterministic.

Vibe coding, or as some prefer to call it, “hands-off” software engineering, is having its moment.

“Words should be weighed, not counted.” — A Yiddish Saying Static code analysis tools count dependencies, calculate ratios, and assign neat scores.

Every other post on my feed celebrates how AI lets us write code faster: whole apps built in a matter of a few hours, 99% AI-generated codebases, hundred-fold productivity gains, and on and on.

Lately I’ve been spending more and more time researching AI models and their effects on software engineering and architecture, so it’s time to share my findings.

This weekend, I have a rare opportunity to write about two things I care deeply about: Domain-Driven Design and Formula 1.

One of the most common pieces of feedback I received about Balancing Coupling in Software Design was that readers wanted a resource they could easily share with colleagues—a quick way to introduce the balanced coupling model and make discussions about it…

My news feed these days: “Take a look at the app I built with zero coding skills!”

My previous post in this series discussed the reliability issues many messaging-based systems suffer from and how to address them by implementing the outbox pattern.

In my previous post in the series, I discussed the basic building blocks for implementing event-driven architecture (EDA) using AWS managed services.

When you couple two components, they need to share some form of knowledge: public interfaces, functional behavior, implementation details, or other types of information.

Frist of all, today is the 🐒 book’s birthday!

The abundance of services provided by AWS often makes it possible to implement the same functionality in different ways.

The microservices honeymoon period is over.

Ladies and Gentlemen, lo and behold a new consistency model - “Optimistic Consistency”.

There is a pet peeve of mine, that I’m encountering way too often: the condition I call Silverbulletitis.

So a few days ago I’ve decided to move to another cellular carrier.

Microservices have taken our industry by storm.

I have quite a few friends in the DDD community.

I’ve always considered Domain-Driven Design’s Bounded Context as a guideline for defining the boundaries of Microservices.

If you’re using Apache NiFi to move data around, you might stumble upon Unicode characters turning into question marks.

The CQRS pattern can do wonders: it can maximize scalability, performance, security, and even “beat” the CAP theorem.

In my previous rant post on TDD I’ve argued that the majority of the problems many experience doing TDD are caused by testing in too narrow scopes - using classes as units of testability, instead of functional use cases.

Let’s do a little experiment: try to explain the gist of Domain-Driven Design to someone who has no clue about it.

One simple question can shed a lot of light on one’s competency in a given field: “On a scale of 1 to 10, please rate your knowledge of [enter-name-of-the-field-here]“.

Last month, I had the pleasure of attending the Domain Driven Design Europe conference in Brussels.

Test Driven Development has been praised by our industry’s aficionados for a long time.

Having spent the majority of my career in the Microsoft stack, lately I’ve decided to step out of my comfort zone and to dive into the world of open source software.

Last week I’ve needed a utility to convert a file containing json data to csv.

If you’ll ever try to generate JSON file using Sql Server’s Management Studio, probably there’ll be lots of pain in your future.

Today I wrote a small script to find and delete duplicate files.

Tight coupling is a known source for inflexible and hard to test code.

On the project I’m working on I’ve had a requirement to store and read files from the file system.

Choosing the right pattern for implementing dependency injection is an important task and can affect your class’s usability and functionality.

The general rule says that if you created an object, then it is your responsibility to dispose it.