Link Dump #206

Have you already read something this month? Friday is a good day for this activity:

Link Dump #205

Hope you enjoyed your holidays as much as you will enjoy reading!

Ubiquitous Language - Boundaries, Words, and the Hidden Cost of Ignoring Them

Today, we begin a detailed exploration of Domain-Driven Design (DDD) patterns — moving from theory into practical examples. In my view, the most powerful and important pattern is Ubiquitous Language. We will examine not only how to use it, but also how to protect it and ensure it evolves alongside the application throughout its lifecycle.

Link Dump #204

Did you already read today? 

The Two Faces of DDD: Strategy vs. Tactics

In today's post, I will explain what Domain-Driven Design (DDD) is, what groups of patterns it includes, how they differ, and how they can help improve your application's quality. 

What is it?

Domain-Driven Design is a collection of patterns that help you align your software more closely with the business it is intended to support. These patterns focus on reflecting domain knowledge - including its language, rules, and constraints - directly within your application. By doing so, they simplify and enhance collaboration with domain experts and stakeholders.

Link Dump #203

In today's world it is hard to predict what happens next. But you can decide what you will read next:

Understanding the Problem and Solution Spaces

Last time, we briefly explored various types of boundaries that should be considered when making architectural decisions for your application. Today, I want to share insights about the Problem and Solution Spaces.

This understanding will support you in defining more effective boundaries — both at the level of services and within the code itself.

Link Dump #202

Today is a good day. With so many new articles to read it cannot be different:

The Secret Geometry Behind Your Architecture

In software architecture, we often talk about boundaries — and for good reason. Boundaries provide valuable insight into various aspects of our systems: cohesion, dependencies, complexity, and more.

Today, I want to walk you through several types of boundaries that should be considered when designing software architecture. Broadly speaking, they fall into two categories:

• Knowledge-specific: These are shaped by business knowledge, requirements, and policies.

• Technical: These are defined by technical constraints and non-functional requirements.

Link Dump #201

Best starter kit for Friday: sun, warm coffee, and articles worth reading. 

From Event Storming to Microservices: A Living Repository

For the past year, I've been quietly crafting something I’ve wanted for a long time—a repository that brings together many of the architectural and development practices I teach, use, and often write about. It’s not a demo for a talk. It’s not a throwaway “hello world.” It’s a living thing: full of decisions, trade-offs, experiments, and structure.

📦 Explore the repository

Inside, you’ll find examples of using:

• Saga, Outbox, Event Sourcing, and CQRS (within services and between them),

• EDA, Ports and Adapters, Strategic & Tactical DDD, Event Storming on all three levels,

• Plus CI, static analysis, testing strategies, ADR, and even some AI usage.

I’ve started also writing blog posts to explain how and why I approached certain problems the way I did — all of them are or will be also linked in the Readme.md. But it will take time to describe everything. If you’re curious, you don’t have to wait. Just dive in.

If you think something’s missing — or you think I got something wrong — tell me. Let’s talk. That’s how we all get better!

After the Big Picture: Turning Insights into Action

Now that you understand what Big Picture Event Storming is, how to facilitate it, and how to overcome common challenges as a facilitator, I believe the series of articles we’ve explored — walking through its steps and possibilities — demonstrate that the knowledge gained by everyone involved truly justifies the time invested in the workshop.

That said, the objective is to cover various stages of developing a Training Center application, to illustrate how techniques like Event Storming, microservices, event-driven architecture, sagas, and many others can work synergistically to improve product quality, architecture, and code. So the natural next question is: what comes after the Big Picture?

Link Dump #200

The greatest things with reading? New things already are waiting for you :)

Big Challenges of Event Storming Big Picture

Event Storming is a powerful technique that helps you learn a lot, but I always emphasize — both in my daily work and in the trainings I conductc — that you need to ensure there is a return on investment in everything you do. That’s why I want to remind you of a few things you should keep in mind as a workshop facilitator, so you don’t end up with just an entertaining session that delivers little value.

Link Dump #199

This is only one article... and then you are lost for hours :)

So… Which Event Goes First?

How to start?

Last time, we walked through the "enforcing timeline" step of Big Picture Event Storming. To begin, we need to choose the first event — but a simple "Let's start" is easier said than done. Let’s explore a few different approaches for deciding which event (or events) we should start with, along with their respective pros and cons.

All approaches can be divided into two categories:

• Close collaboration — everyone works together all the time.

• Working in silos — people work alone or in smaller groups and merge their outcomes later.

Link Dump #198

I hope you agree this is the right moment for a coffee and reading.

Event Storming Big Picture — How to enforce the Timeline?

We have completed the first step of our workshop. The chaotic exploration and following discussion allowed us to visualize a wealth of information: events, hot spots, and opportunities. We are starting to align our understanding of concepts and terminology.

Before moving to the next step — enforcing the timeline — let’s briefly revisit what we have produced so far:

You may also want to remind yourself of the high-level requirements.

Now that we know where we stand, let’s see how we can use the outcome from the previous sessions.

Link Dump #197

The best thing in reading? Can be done everywhere at any time :)

Link Dump #196

Did you ever wonder what is the best day for reading? I would say the best is "every" :)

Link Dump #195

Sun - checked! Friday - checked! Something to read - checked!

Link Dump #194

Friday the 13th - what can go wrong?

Link Dump #193

Friday, coffee or reading - what's the best? Today it doesn't matter - you got it all:

The AI Productivity Trap: More Code, Less Thought?

 Can the quality of code degrade much faster because, with AI, new engineers may have fewer opportunities to practice and learn? But what about experienced engineers? Could we become so overwhelmed by the volume of code to review that we start becoming sloppy?

Link Dump #192

Another great day is another great reason to read another great article:

What Running Your Application Can Tell You About Its Quality?

I mostly work with long-lived applications that undergo continuous modification. Evaluating their quality by simply glancing at the code would be rather naive—there are multiple dimensions to consider for a more comprehensive assessment. Of course, code quality matters, but there are several other checks I perform. Today, I want to share a subset of those checks—focused specifically on application execution—and what insights they can offer.

Link Dump #191

Article, book, audiobook, podcast? It doesn't matter as long as it makes you happy :)

Do You Understand the Debt You Have to Pay?

I was fortunate to start my career with people who truly cared about code quality. Early on, I learned why this matters and how continuous attention to quality positively impacts customer satisfaction. This experience made it natural for me to improve legacy code and constantly seek further enhancements.

However, at the beginning of my journey, my perspective was narrow—I saw only the code. So, my efforts focused solely on refactoring. Fast forward to today, I've learned that there are many more ways to improve software. There are also several strategies you can explore to choose the right approach for your situation.

Link Dump #190

Not each Friday can be sunny, but good thing is - each is good for reading:

Link Dump #189

Sunny day = reading day :)

Link Dump #188

Never ending cycle: yet another word, yet another article, and it's Friday so you have to start again :)

Link Dump #187

Today is a good day... good day to read another great article:

Link Dump #186

The dilemma of the week comes back - what should you read first?

Link Dump #185

And this difficult decision to make - what to read first:

Why Your Brilliant Ideas Fall Flat (And How to Fix It)

We all know the drill: refactoring makes our code easier to understand, static analysis points out complex areas and code smells, tests help us track and improve our code's coverage, and Domain-Driven Design lets us build code that directly reflects the business rules. Sounds logical, right? Yet, we often find it tough to convince managers, product owners, and other stakeholders of the value in these practices. What's even more puzzling is that we usually have no problem getting fellow developers on board.

Link Dump #184

April Fool's over so jokes aside - new recommendations are here!

When 'Best Practices' Bite You

I know it's a cliché, but there's no silver bullet. Is refactoring always worth it? No. Is Test-Driven Development always beneficial? Of course not. Should you always add test scenarios to cover every known gap? No. Should automated tests be your goal in every project? Again, no.

Don't get me wrong, I'm far from advocating against these solutions. In fact, I recommend quite the opposite; you should have a compelling reason not to use them. And trust me, your project is likely not as unique as you think. In most cases, developers' arguments against these practices are excuses, not justifications.

However, we should give each decision a moment of reflection and assess whether the benefits truly outweigh the costs. Even your favorite approaches can increase costs and slow down implementation at best, or render it unprofitable at worst.

Link Dump #183

First quarter of 2025 is almost over. Great! So much reading in front of us in 2025 left :)

Dealing with legacy is more than the right architecture

So, picture this: you're stuck working on this old, massive monolith, and for years, it's the same old story – we gotta fix this, 'cause delivery's crawling, and keeping developers happy (or even hiring new ones!) is a nightmare.

Link Dump #182

Friday, coffee, reading, weekend:

Link Dump #181

Let's be honest, we all need coffee and something worth reading:

Link Dump #180

Friday, coffee, something to read - couldn't be better :)

Link Dump #179

May your coffee be strong, and your reading list long! 

Link Dump #178

Friday, coffee, something good to read... perfect moments exist :)

Link Dump #177

The next great thing? For sure a book, but which one? This is the question!

Link Dump #176

How about one more article... or a book... or a few :)

Link Dump #175

How about making Friday great again and read something interesting?

Link Dump #174

Friday = coffee + something to read. Ok, I can survive without coffee :P

Link Dump #173

Did you already read a book this year? Regardless of the answer, how about an article? Or two?

Link Dump #172

Ready or not, here it comes - new articles to read :)

Link Dump #171

You know that I know that you know what is the best way to start a New Year :)