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.