Mind the Architecture

This month I started a new blog - Mind The Architecture. Why? Because it felt like the right moment to do it. As the saying goes: "the only constant is change." Sometimes you simply need to change things around you to reset your mind and make space for new ideas. The change does not always need to be huge, but it should be noticeable.

For me, that change is a new blog with a new name and a new address. I do not treat it as a fresh beginning, but rather as an evolution. I decided to become more focused and intentional about writing and sharing knowledge through different channels. Last year I spent time turning this intention into a habit, and now it feels like the right moment to transform that personal habit into a public activity.

As I said, this is not a start. I have been writing for the last 15 years, although I did not even realize how long it had been until I checked the statistics:

• Let's Talk about Java - 2013 - 2026, 13 years, 323 articles
• Between Success and Failure - 2012 - 2016, 4 years, 53 articles
• Programistyka - 2011 - 2015, 4 years, 97 articles

In total, that is 473 articles — about 31.5 per year, or roughly 2.5 per month. I would call that quite an achievement.

So why start a new blog? There is no deep story behind it. I simply wanted to create a place where I can continue sharing knowledge and practical solutions about building software that can evolve easily over time. The name "Let's Talk About Java" is no longer a good fit, because over the years the content I share has become increasingly language-agnostic.

Now I want to help you Mind The Architecture.

Architecture is a journey, not a destination. It needs to evolve and adapt so that the software you build can continuously support changing business needs.

I hope you find the ideas here interesting.

Let's stay in touch:

• GitHub
• LinkedIn
• Twitter

Link Dump #225

It's Friday! Grab your coffee, take something good to read and enjoy the moment :)

Link Dump #224

One article, two articles, three... and it's Friday so how about one more?

Link Dump #223

What is the best coffee you can have? The one you drink having a book in your hand.

Link Dump #222

What's your mood today? I assume this is a mood for reading :)

Link Dump #221

I assume your New Year's resolutions list may already be full, but how about adding one reading-related?

Link Dump #220

I know this is not a Christmas gift, but I'm sure you will find something for yourself :) 

Link Dump #219

It's reading time! And grab a cup of coffee with you - you might lose track of time!

Link Dump #218

There's still a couple of weeks of reading this year in front of us. Let's use it well :)

Link Dump #217

Every day is good for reading, but Friday is even better :)

So… Which Part of Your System Is Actually Worth Building?

Domain types classification is part of the problem space. It increases our understanding of the business, its priorities, and its main aspects. On the other hand, it is not part of the implementation itself. However, this does not mean it lacks value — it still provides insights that help us make better, more informed software architecture decisions. Let's explore how domain classification can support us in this process.

Link Dump #216

Winter is coming but you shall not be afraid - a new Link Dump is coming too :)

Link Dump #215

Ready for Friday? With a new set of worth reading articles I bet you are :)

Link Dump #214

Another book or maybe a short article? How about both :)

Link Dump #213

I know I do not have to convince you to read but remember that reading improves your focus and memory :)

Core, Supporting, Generic – How to Stop Treating All Domains the Same

Most businesses require knowledge from multiple domains to be successful. Some are essential due to the nature of the business itself, others are mandated by legal regulations and compliance obligations, and some exist simply to meet specific operational requirements.

After the last series of articles, you already know how to identify those domains. But what comes next? Once we define all domains, it’s worth categorizing them. This exercise helps us later make better software architecture decisions and organize teams more effectively.

Link Dump #212

I've got enough reading - said no one ever.

The Hidden Architecture of Words — Ubiquitous Language Uncovered

Over the past weeks, I’ve been diving into one of the cornerstones of Domain-Driven Design — Ubiquitous Language. It’s not just about naming things right. It’s about creating a shared language that bridges business and technology, reduces misunderstandings, and makes complex systems easier to reason about.

To make the idea practical, I’ve prepared a short series that walks through it step by step — from understanding what Ubiquitous Language really is, to finding it in your domain, and finally applying it in action.

Link Dump #211

Another Friday, another coffee, and more articles to read. Routine does not have to be boring:

Ubiquitous Language in Action: Boundaries Made of Words

You already know what the Ubiquitous Language is and how to define its boundaries. Equipped with that knowledge, let’s return to the Training Center example and clarify what domains and corresponding ubiquitous languages we have.