let's talk about Java

Mind the Architecture

2026-03-15T11:58:00.000-07:00

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:

Link Dump #225

2026-01-30T01:00:00.000-08:00

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

Software Architecture
1. The Paradox of Abstraction: Why Good Abstractions Make Systems Harder to Debug
  We’re taught that abstraction is the key to elegant, maintainable code - but does it come at too high a cost? This article dives into the paradox of modern development: the very layers that hide complexity also hide the clues we need when things break.
2. Simple Is Hard. Primitive Is Easy. #PickOfTheWeek
  True simplicity is the ultimate sophistication, but it’s remarkably hard to achieve. Learn why the hardest part of software engineering isn't adding features, but finding the elegant, simple core that remains after all the 'noise' and 'primitive' hacks have been removed.
Software Development
1. DevOps: The Never-Ending Story
  This post breaks down why 'failed' is the wrong word for a movement that has defined an entire generation of engineering careers and why its lack of a rigid manifesto turned out to be its greatest competitive advantage.
2. SPAs Are a Performance Dead End
  Why does a massive site like Stack Overflow feel instantaneous while modern SPAs feel sluggish? The secret isn't more JavaScript; it's less. This article explores why delivering full, server-rendered HTML is often superior to the 'fragmented' delivery model of apps like LinkedIn and Facebook.
3. Apache IoTDB Introduction
  Apache IoTDB offers an open-source, distributed alternative that treats timestamps as first-class citizens. This article covers key features like advanced column-oriented compression, a SQL-like query language, and seamless Java integration.
Code Quality
1. In the age of AI coding, code quality still matters #PickOfTheWeek
  Natural language is too ambiguous to define complex systems, which is why programming languages exist in the first place. Learn why high-quality code is the best way to 'speak' to your AI tools, ensuring they generate predictable, secure, and maintainable solutions instead of hallucinated technical debt.
Leadership
1. Limited Autonomy Is the Main Reason for Low Engagement Levels #PickOfTheWeek
  The author argues that we are facing a massive autonomy gap. Building on Dan Pink’s classic framework of Motivation, he explores how traditional hierarchies are designed to hoard decision-making power, effectively killing mastery and purpose in the process. Learn why the "illusion of choice" is often more damaging than having no choice at all.
2. Is every problem truly a leadership problem? #PickOfTheWeek
  By categorizing challenges into Expertise, Systemic, Polarities, and Adaptive, the author reveals why sheer will and charisma can’t fix a complex bug or bend the laws of physics. Learn why understanding the 'domain' of a problem is the first step toward solving it.
3. The Compassion Paradox
  This article examines the fine line between being a supportive coach and a shield that prevents growth. By embracing the paradox of keeping the pressure on while providing a safety net of support, leaders can help their teams sharpen their potential rather than creating a culture of dependency.

Link Dump #224

2026-01-23T01:00:00.000-08:00

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

Software Architecture
1. The Anthropology of Legacy Systems
  Every codebase is a historical record. This article treats legacy systems like archaeological strata, revealing how we transitioned from memory-saving Perl scripts in the 90s to the religious devotion to design patterns in the 2000s. Learn to read the 'geological layers' of your code to understand the pressures and priorities of the developers who came before you.
2. There are no silver bullets - GenAI included
  While simple narratives are easier to sell, they often ignore the nuance and context required for real-world success. Learn why acknowledging a tool's limitations is actually a sign of deep expertise, not a lack of vision.
3. Reimagining LinkedIn’s search tech stack
  This technical deep dive explores the high-level components of LinkedIn's AI-powered stack. Discover how they manage the 'auction layer' to balance user engagement with business metrics, ensuring every search provides a path to a real professional opportunity.
Software Development
1. HTTP Is the New MCP #PickOfTheWeek
  Every time the industry invents a 'universal protocol,' we get fragmentation and high implementation costs. This post challenges the hype around new agent-to-service handshakes, proposing that HTTP - with its mature security and global addressing - is already the perfect home for agents.
Code Quality
1. Legacy modernization in the age of AI
  Learn how Thoughtworks used AI to modernize a custom-built app in six weeks vs. an estimate of six months.
Agile
1. Stop Picking Sides #PickOfTheWeek
  Jim Highsmith argues that the decades-long battle between 'Agile' and 'Traditional' development is a false dichotomy that misses the point. The real challenge isn't choosing a tribe; it's managing the tension between adaptation (learning under uncertainty) and optimization (reliability under constraints).
Leadership
1. The Best Leaders Are Great Followers
  This article explores the radical idea that leadership and followership are a fluid, co-created process rather than a fixed hierarchy. Discover the five core 'followership' capabilities that separate ego-driven managers from the impactful leaders.
2. Information, Understanding and Action #PickOfTheWeek
  How do you know which team members you can truly count on? This article suggests a practical experiment: give volunteers a small, real-world project to test their execution skills. It’s a lesson in finding a person’s 'failure point' allowing you to coach them exactly where they need it most.
Growth
1. Why Soft Skills Outlast Technical Skills on Product Development Teams #PickOfTheWeek
  Discover why soft skills are actually 'risk reducers' that help teams navigate evolving requirements and stakeholder trust. It’s a reminder that when the pressure is on, a team’s ability to have hard conversations matters more than their coding speed.

Link Dump #223

2026-01-16T01:00:00.000-08:00

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

Software Architecture
1. Fundamentals First
  The most valuable engineers are quietly building foundations that compound over decades. This deep dive explores why Docker, Transformers, and MCP aren't actually new, but clever recombinations of concepts from the 50s, 90s, and early 2000s. Learn why slowing down to master the layers beneath your code is the only way to stay ahead in an AI-augmented future.
2. A World Without Kafka #PickOfTheWeek
  This post explores why Kafka’s record-based architecture is increasingly hitting a wall as real-time analytics and decision-making demands grow. Discover why Ververica is looking beyond traditional message queues toward a future of unified streaming storage.
Software Development
1. On the duality of GenAI-based development tools
  AI tools act as an organizational accelerant, but are you accelerating toward success or a crash? For organizations with weak feedback loops, AI simply speeds up the creation of rework and operational risk. For those built for rapid learning, it’s a powerful productivity booster.
2. Comments Considered Harmful in the Age of LLMs #PickOfTheWeek
  Is code documentation dead? The author argues that manual comments are just stale lies waiting to happen. In the age of AI, we should prohibit comments entirely and use LLMs to generate explanations on-demand. If an AI can’t interpret your code, the problem isn't the documentation—it’s your code. Learn why your next build should fail based on a 'Code Interpretability Score.'
3. Unknown Mistakes to Avoid in Software Development #PickOfTheWeek
  This post explores common but overlooked pitfalls in the development process, including the premature optimization of team workflows and the failure to align technical decisions with long-term business goals. Learn how to identify these 'invisible' traps before they evolve into insurmountable technical debt.
Clean Code
1. Code as Literature
  Every codebase has a voice and every class tells a story. Learn to treat refactoring as an editorial revision, cutting out the 'shit' of the first draft to find the essential logic beneath.
2. The Psychology of Code Reviews: Why Smart Developers Accept Bad Suggestions #PickOfTheWeek
  Code reviews are supposed to be objective, but they are often complex social negotiations. This article dives into the psychological forces that lead smart developers to approve bad code. Learn why seniority often trumps evidence and how unspoken hierarchies can quietly sabotage your system's quality.
Leadership
1. Illusion of Control
  This post explores the realization that the harder a manager tries to control pace and decisions, the slower and more passive-aggressive a team becomes. Learn why letting go of the steering wheel is often the only way to keep the engine running.
2. Comfort is Toxic #PickOfTheWeek
  Comfort is a warning. Don’t wait for failure to change. Abandon what’s working before it fails.

Link Dump #222

2026-01-09T01:00:00.000-08:00

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

Software Architecture
1. The Ethics and Philosophy of Data Governance in Modern Business
  Data is often called 'the new oil,' but it's time to view it as a moral responsibility. Learn how shifting from 'risk avoidance' to 'values-based governance' can build lasting trust with your customers.
Testing
1. Avoiding Fake Drift in Unit Tests #PickOfTheWeek
  Fakes are often superior to mocks because they allow for true behavior verification, but they come with a hidden risk: Fake Drift. This happens when your test double evolves separately from the real implementation, leading to tests that pass while the production code fails. Learn how to keep your fakes in sync and maintain the integrity of your test suite.
Agile
1. Are You Really Doing Scrum? A Practical Scrum Litmus Test #PickOfTheWeek
  Scrum is lightweight for a reason: every rule exists to drive transparency and inspection. Explore the deeper layers of a healthy Scrum implementation and learn why living the five Scrum values is the ultimate test of agility.
Leadership
1. Why AI Boosts Creativity for Some Employees but Not Others
  New research reveals that AI boosts creativity primarily for employees with strong metacognition - the ability to plan, monitor, and refine thinking. Organizations that cultivate such skills will turn AI from a productivity tool into a sustained source of creative advantage.
Fun
1. Me and my Udemy courses

Link Dump #221

2026-01-02T01:00:00.000-08:00

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

#BookOfTheMonth The Unicorn Project
Software Architecture
1. API Design: REST, GraphQL, gRPC Comparison
  Architecture is all about trade-offs. This article compares the three heavyweights of API design - REST, GraphQL, and gRPC. Learn why REST remains the pragmatic default for public APIs, how GraphQL solves the 'N+1' query problem for mobile apps, and why gRPC is the gold standard for high-performance internal microservices.
Software Development
1. Why developers aren't like figure skaters? #PickOfTheWeek
  The author critiques the rise of the 'sacred cow' developer who focuses on technical abstractions like hexagonal architecture and microservices simply because they’re trendy, not because they’re needed. Discover why true seniority is measured by your ability to connect everyday work to how a company creates value, not by the number of buzzwords in your CV.
Languages and Libraries
1. What’s New in Maven 4
  Maven 4 introduces native support for multiple Source Directories and Condition-Based Profiles, allowing for more flexible, logic-driven build configurations. Dive into features like Parent Inference and new artifact types that make managing Java Modules and annotation processors simpler than ever.
Leadership
1. Questions aren't curiosity
  Asking questions isn't the same as being curious. Most 'work questions' aim for speed, compliance, and closure, but curiosity seeks understanding. Learn why work questions move tasks forward, while curious inquiries move people forward. Stop collecting data and start inviting thinking.
2. AI Tools Make Coders More Important, Not Less #PickOfTheWeek
  Many leaders are excited about the promise of AI coding tools that can make it easier for novices to write code and, seemingly, make experienced coders less essential. Yet these tools make experience more important, as AI is not a replacement for real engineers. Learn why it is important to keep experienced engineers in charge of the design, the rules, and the safety checks.
Communication
1. Filler words are not as bad as you might think #PickOfTheWeek
  This post argues that filler words aren't just 'noise' - they actually make you sound more human and relatable. Learn why a perfectly polished, filler-free speech can sometimes come across as robotic, and how these small pauses give your audience vital time to process your message.
Fun
1. A Case of Old Code

Link Dump #220

2025-12-19T01:36:00.000-08:00

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

Software Architecture
1. Event Sourcing vs CRUD: Rethinking Data Persistence in Enterprise Systems #PickOfTheWeek
  This article explores how Event Sourcing inverts the traditional model by recording every change as an immutable event. Instead of just seeing the final state, you gain a complete 'story' of your data, making audit trails and system recovery intrinsic features.
2. Neuromorphic Computing and Brain-Inspired Architectures #PickOfTheWeek
  Discover why Spiking Neural Networks are becoming the gold standard for edge intelligence, offering razor-thin latency and biological plausibility for the next generation of brain-machine interfaces.
Software Development
1. Proactive Problem-Solving: Observability Trends Every Leader Should Know
  This article outlines the fundamental shift toward predictive observability, where organizations use centralized data to solve problems before they impact the user.
2. Introduction to the Model Context Protocol (MCP)
  The Model Context Protocol (MCP) is an open-source standard designed to be the 'USB-C port' for AI applications. Learn how to connect your Java apps to the AI ecosystem using a unified, consistent interface.
Leadership
1. Thinking Doesn’t Make It So #PickOfTheWeek
  This post argues that while negative thoughts can pull you down, positive thinking alone won’t lift you up - only action does. Learn why competence is earned through doing, and why you should replace 'I think' with 'I will' to bridge the gap between visualization and reality.
2. Why Teams Matter More Than Ever for Innovation #PickOfTheWeek
  Sometimes all it takes for an innovation breakthrough is a single question: 'What problem are we really trying to solve?' Learn how to move your team from a collection of individuals in a work group to a cohesive unit that thrives on curiosity.

Link Dump #219

2025-12-12T01:00:00.000-08:00

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

Software Architecture
1. Designing for Failure: 4 Resilience Practices That Make Outages Boring #PickOfTheWeek
  Outages are only scary when you can't contain them. Discover four architectural practices that isolate damage and improve system stability.
Software Development
1. Event Storming Big Picture: How to Enforce the Timeline #PickOfTheWeek
  The "Enforcing Timeline" phase orders chaotic events chronologically on a horizontal timeline to clarify process flows and dependencies.
Growth
1. Why Leaders Don’t Seek Feedback
  Giving feedback is easier than seeking it, so how do you become a pro at asking? Learn five ways to seek feedback like a pro.
Leadership
1. 6 Dumb Leadership Mistakes
  This post lists 6 persistently dumb leadership blunders that we commit even though we know better. Find out which self-destructive habits are holding you back.
2. Stop Building Teams Like You're Assembling a Backend Army #PickOfTheWeek
  Are you missing the skills you need for your next project? Learn to map your team's real strengths and weaknesses to ensure your team is built to deliver strategic business outcomes.

Link Dump #218

2025-12-05T01:00:00.000-08:00

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

#BookOfTheMonth
Inspired
Software Architecture
1. Buy vs. Build: The Software Decision That’s Less About Magic and More About Logic
  Stop treating 'buy vs. build' as an only IT problem! This post argues that the decision must be a strategic organizational one. Learn to apply the core heuristic: If a function differentiates you, build it in-house; otherwise, buy it, and why business leaders must set this direction first.
2. Service Mesh vs API Gateway
  The choice between an API Gateway and Service Mesh depends on your architecture's maturity and needs. Discover the trade-offs between their centralized vs. distributed deployment.
3. We Outsourced All Our IT Problems to an IT Vendor and Now We’re Just Left With Problems #PickOfTheWeek
  Choosing the right engagement model is a strategic imperative. Do you need Lean, Six Sigma, or Agile? This article breaks down the three primary models for outsourcing: Product (best for stable, predictable outcomes), Utility (best for standardized, metered resources), and Co-creation (best for complex, evolving digital transformation). Match your methodology to your model!
4. Reactive Programming Paradigms: Mastering Backpressure and Stream Processing
  Reactive programming is a complete paradigm shift, not just a technical trend. Dive into the four characteristics of the Reactive Manifesto: Responsive, Resilient, Elastic, and Message-Driven.
Agile
1. AI Doesn’t Eliminate Agile Teams — It Increases the Need for Great Ones #PickOfTheWeek
  AI accelerates development, leading many teams to unintentionally collaborate less. This article argues that AI doesn't eliminate agile teams - it makes great ones essential. Learn why the risk is not the technology itself, but the resulting misalignment that is magnified by speed.
Leadership
1. Problem-Solving that Works #PickOfTheWeek
  The problem with problem-solving is distorted thinking. This article argues that true solutions lie in behaviors, not ideas. Learn to distill issues by asking: 'What are people doing that causes this issue?' and 'What behaviors are likely to produce desired outcomes?'

Link Dump #217

2025-11-28T01:00:00.000-08:00

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

Software Architecture
1. Five Hard Lessons from Recovering a Catastrophic Microservices Migration
  The author explains that successful architectural recovery depends as much on perception management and team dynamics as on technical prowess.
2. So… Which Part of Your System Is Actually Worth Building? #PickOfTheWeek
  By understanding which parts of the system are core, supporting, or generic, we can decide what to build, what to buy, and what to outsource without guesswork. And as the business evolves, this classification helps us adapt confidently instead of chasing changes blindly. Read the article and learn how to learn more from your domains' classification.
Software Development
1. Data Privacy as Strategic Opportunity in a Cookieless Future
  This article argues that brands treating data privacy as a feature, not a bug, are winning customer loyalty. Learn why first-party data is the new gold, replacing sketchy third-party surveillance.
2. The Evolution of User Experience Design #PickOfTheWeek
  This article reveals why design-driven companies outperform the S&P Index by 228% and how a comprehensive UX strategy can increase conversion rates by up to 400%. Discover why investing in user experience isn't a cost but a competitive necessity.
3. The Coding Assistant Bottleneck: Applying the 3-Ways #PickOfTheWeek
  Learn how local efficiencies lead to global slowdowns. To understand why this is happening and what to do about it, we need to go back to basics. We need to look at this new reality through the lens of the Three Ways of DevOps.
Testing
1. What’s New for Testing in Spring Boot 4 and Spring Framework 7
  This article explores the key testing-related updates for Spring Boot 4.0 and Spring Framework 7. This includes the new modular architecture, the improved test context management, and practical guidance for a smooth transition to this new major release.
Leadership
1. 3 Quiet Weeks #PickOfTheWeek
  The author advises leaders to avoid the 'shoe-drop' anxiety when things are going well. Instead, view margin as an opportunity to reinvest: improve a process, remove obstacles, or equip competent people for new challenges by delegating.
2. How to Build Engineering Teams That Drive Outcomes, not Outputs
  Learn how to anchor engineering, product, and design around a shared outcome to drive flexibility and collective ownership.

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

2025-11-27T01:00:00.000-08:00

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.

Architecture Evolution

Today we will make a few initial decisions, but they may change later. To be honest, this is not a problem because:

every decision moves us forward
accepting the changes that will inevitably come forces us to design architecture in a way that supports evolution — a beneficial characteristic for any product we build

Build or Buy?

How can domain classification help us in the solution space?

First, by guiding us toward understanding which problems we should solve ourselves and where we should explore existing solutions. It’s important to emphasize that “buying” a solution does not have to be literal. It may be something already created and used within our company or an open‑source library. The key point is that it already exists and satisfies our expectations.

Generic Subdomains

Let’s start with generic subdomains. On their own, they can be quite complex. I don’t know anyone who would call Accounting simple. Yet we need these subdomains because they are required. They do not bring competitive advantage and, in most cases, we lack the domain expertise to understand them deeply. These are strong candidates for solutions worth buying. Problems from these domains can be solved in ways supported by their providers. It does not have to be implemented exactly as we would prefer. If the cost is acceptable and the features meet our needs, we can learn to use the existing solution.

From an architecture perspective, these external solutions may even remain outside of our direct interest due to minimal or manual integration with the system we implement.

Supporting Subdomains

Now let’s consider another category — supporting subdomains. Here, we should also look for solutions that already exist. However, in this case, we more often talk about services and tools that we will need to integrate with, even if we decide to acquire an external solution. This is simply because these subdomains support our core domains, which implies closer interaction.

Sometimes integration will not be enough, and we will need to add extensions crucial for the product we are building.

As you can see, coding within these subdomains is quite common. It might not be the most complex part from a business perspective, but it still requires development effort.

Core Domains

When we talk about core domains, we refer to areas where solutions must be built by us — especially where we seek competitive advantage. If that’s not the case, then perhaps our classification was inaccurate.

Build or Outsource?

Once we know what has to be built, we can move to the next question: what can be outsourced?

Generic Subdomains

If nothing suitable exists on the market, this becomes a good candidate for outsourcing. Perhaps there is already a company specializing in such solutions — use their expertise.

However, if no one provides it, maybe your classification was incorrect and you’ve discovered another core domain. Or a new product to build.

Supporting Subdomains

On one hand, this can also be a good candidate for outsourcing. After all, it’s not your core domain. On the other hand, you already know that domains evolve, and a supporting subdomain may eventually become a core domain.

Taking that into account, I recommend outsourcing only if the implementation focuses mostly on integration with another domain. If the supporting subdomain must be built from scratch or requires extending existing solutions, I suggest keeping the implementation in‑house. This ensures you maintain domain expertise and avoid creating a dependency on an external provider — especially important in case the subdomain evolves.

Core Domains

Core domains should be fully implemented by us. Since they represent the most important parts of our system, we must ensure domain expertise stays within the team. We don’t want to share this knowledge or rely on external vendors.

Decisions Can Be Changed

At this stage, we do not yet have full, deep understanding of the business, and some important aspects may still be outside our view. The more we learn, the more accurate our decisions become. This means decisions made now may change — and that’s perfectly fine. It’s better to move forward, adapt, and evolve than wait indefinitely for complete knowledge.

New information is not the only reason decisions might shift. When evaluating what we can buy, we may discover solutions we weren’t aware of before. Or we might assume something has the features we need but later find out it doesn’t. Or we expect the price to be acceptable but it turns out not to be. Additionally, something we built ourselves may later appear on the market as an off‑the‑shelf offering worth considering.

The market is not set in stone, so it is worth monitoring to stay informed and react when needed.

Summary

Domain types are not only a theoretical classification — they guide us toward better‑informed decisions. Thanks to this classification, it becomes easier to determine what to buy and what to build. It can even challenge our assumptions, especially if all our “core domains” turn out to be available on the market. But that’s not all. Using this classification, we can better manage risk and decide which aspects of the system are safe to outsource and which must stay with us — both in terms of domain expertise and implementation.

Link Dump #216

2025-11-21T01:00:00.000-08:00

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

Software Architecture
1. Platform Engineering: Rethinking Developer Experience in the Age of Complexity
  This article explains the shift-down philosophy: rather than pushing all operational burden onto developers ('shift left'), the platform team assumes responsibility for infrastructure, security, and compliance
2. Requeuing Roulette in Event-Driven Architecture and Messaging #PickOfTheWeek
  This article explains that when messages are 'causally correlated', parallel processing is dangerous. Requeuing Roulette attempts to cheat this trade-off but risks making correlated messages skip the line, leading to race conditions and unexpected failures.
Software Development
1. Vibe Coding: The Double-Edged Sword in Modern Software Development
  Vibe Coding is development driven by immediate gratification and rapid prototyping, but it creates a Cognitive Load Crisis for security. Discover why this short-term thinking often leads to fundamental architectural flaws and technical debt that are expensive to fix.
2. Agile Git Branching Strategies in 2026 #PickOfTheWeek
  Adopting Trunk-Based Development is a cultural shift, not just a process change. This article stresses that moving to daily commits on the trunk requires a high-trust environment where the team collectively owns quality.
3. Why Does Development Slow? #PickOfTheWeek
  The author explains that the 'mess' in your current code creates a gap. Discover how deliberate tidying closes this gap by creating options—the freedom to build—and how this simple rhythm sustains velocity.
Clean Code
1. Small Repo, High Quality #PickOfTheWeek
  This article argues that smaller repositories lead to better code because they allow for stricter style enforcement, deeper and faster integration tests, and more pedantic code review due to reduced complexity.
Agile
1. Rethink the Refinement Session: Less Time, Better Outcomes
  Is your team spending too much time in backlog refinement? This article argues that more time is wasted here than in all other meetings combined. The fix: Treat refinement as a quick pre-planning check, not a deep-dive workshop.
Fun

Are You Mocking Me?

Link Dump #215

2025-11-14T01:00:00.000-08:00

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

Software Architecture
1. Service Mesh Architecture
  This article introduces the Service Mesh as the essential architecture to manage distributed systems. Discover how control planes like Istio and data planes like Envoy standardize traffic control, security, and monitoring outside of your application code.
2. Are Your ADRs Write-Only Documentation? #PickOfTheWeek
  Discover how to transform your ADRs from passive historical logs into active communication tools that onboard new team members and align current development.
3. Micrometer’s Observation API: Unified Observability for the JVM
  Learn how Micrometer’s Observation API fundamentally changes the JVM observability landscape by bringing vendor-neutral, unified metrics and tracing with unprecedented sophistication.
Software Development
1. Vibe Coding Can Create Unseen Vulnerabilities
  This article explains how generating software without visibility into the code structure creates significant challenges for security and maintenance. The result is hidden vulnerabilities, increased technical debt, and difficulty with debugging complex integrations.
2. Can’t Merge? Don't Despair.
  This guide offers advanced tactics for dealing with un-mergeable code. Discover why you should never use your failed PR as proof of a flaw, but instead submit a separate bug report as if you were a complete stranger who just found a defect in the master branch.
3. Vibe Coding vs. Spec-Driven Development #PickOfTheWeek
  The author, dives into the rise of vibe coding versus traditional spec-driven development.
4. The Abstraction Paradox: Why Programming Languages Keep Getting More Complex
  Every few years, a new programming language promises to make coding simpler. Yet somehow, the barrier to entry keeps rising. We’ve created an abstraction paradox: the tools meant to make programming easier have made it more complex.
5. In the Age of AI, Your Data Has a Future — But Only If It Has a Past #PickOfTheWeek
  This article explains the uncomfortable truth: Snapshots tell you what happened; events tell you how and why. In the age of AI, the ability to learn patterns of change, not just static states, makes historical event data suddenly and profoundly strategic.
Languages and Frameworks
1. Java 25: A Leaner, Smarter, and More Expressive Future
  Java 25 marks a pivotal moment in the evolution of the language—refining its core strengths while embracing modern programming paradigms. With a focus on performance, developer ergonomics, and concurrency, this release builds on the momentum of Java 17 and 21, offering features that feel both familiar and fresh.
2. Spring AI Integration: Building Intelligent Java Applications
  Let’s explore how Spring AI brings familiar Spring patterns to the world of generative AI.
Testing
1. Composable Tests #PickOfTheWeek
  Kent Beck dives into the difference between Isolation and Composition in testing. He argues that while Isolation ensures tests run independently, Composition is about structuring the overall suite so that combining multiple, focused tests gives you predictive confidence in the system's total coverage.
Agile
1. Nurturing a Self-Organizing Team through the Daily Scrum #PickOfTheWeek
  The daily scrum should be fuel, not a status report. This article coaches Scrum Masters on how to take a back seat and nurture a truly self-organizing team.
Leadership
1. 7 Ways to Get More Done and Still Have Fun
  This guide emphasizes that efficiency requires eliminating distractions and novelty. Learn why developing rigid routines saves energy, enabling you to find quiet and focus on what truly matters during your most productive hours.
2. Who is Underperforming?
  Stop blaming your staff for missed deadlines. This management insight explains why the responsibility for underperformance flows up, not down.

Link Dump #214

2025-11-07T01:00:00.000-08:00

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

#BookOfTheMonth
Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies
Software Architecture
1. Software Architecture as Living Documentation Series
  This is a series of posts exploring how to automatically extract software architecture and domain concepts from a codebase to have 100% reliable living documentation across a whole system.
2. Choosing a dependency #PickOfTheWeek
  Choosing a third-party dependency is a critical risk management activity. This article details the essential steps to handle the risks of external code. It also guides you through the fundamental build vs. buy decision, using practical examples.
Software Development
1. Macro trends in the tech industry | November 2025
  The latest edition of the Thoughtworks Technology Radar is out. This article expands on the macro trends that informed Thoughtworks discussions during the Radar meeting.
2. Handling Events Coming in an Unknown Order #PickOfTheWeek
  This article tackles the toughest ordering problem in Event-Driven Architectures: knowing what data is complete when messages arrive out of sync. Learn the powerful strategy of separating Internal vs. External Events, using a Summary Event as a public contract to minimize ordering issues and prevent cross-module dependencies.
Languages and Frameworks
1. Java 25: Understanding Stable Values
  Let delve into understanding Java 25 Stable Values and how they simplify concurrency handling, improve application performance, and ensure immutability without compromising thread safety.
2. Unnamed Patterns and Variables: Reducing Boilerplate #PickOfTheWeek
  Unnamed patterns and variables—often called discards or wildcards—are reshaping how we handle data we don’t care about, making code cleaner, more intentional, and remarkably more readable.
3. The Long Journey - How Bytecode Gets Interpreted by the Machine #PickOfTheWeek
  This article dives deep into the JVM's tiered compilation process, explaining how bytecode is converted into highly optimized native code across five different levels. Discover why the JIT compiler initially uses a fast Interpreter before moving hot methods through the C1 and C2 optimizing compilers.
Leadership
1. Simple Skills—Strong Leadership
  Discover how to lead from any position by mastering basic yet profound skills.
2. To Achieve the Extraordinary, Focus on the Game Changers #PickOfTheWeek
  What defines a true Game Changer in your organization? Learn how to scout and recognize the few people who can propel your entire team forward.

Link Dump #213

2025-10-31T02:00:00.000-07:00

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

Software Architecture
1. Core, Supporting, Generic – How to Stop Treating All Domains the Same #PickOfTheWeek
  Most of the time, we talk about domains as if they were all the same. But they’re not — some drive your business forward, others just keep it running. In this article, we’ll look at how to spot which domains deserve your time, attention, and money — and which ones you can safely buy off the shelf.
2. Functional Choreography for Microservices: From Theory to Practice
  Is your microservices workflow a distributed monolith? This article contrasts rigid orchestration with flexible choreography, where services react to events instead of receiving direct orders.
3. Emerging Patterns in Large-Scale Event-Driven AI Systems
  Build scalable AI event pipelines with Kafka to enable continuous learning systems that perceive, reason, and act in real time.
Software Development
1. 7 Proven Benefits of DevOps Implementation in Modern Software Development
  Discover how automation and continuous testing ensure updates are deployed faster, more frequently, and with rock-solid reliability.
2. Agentic AI and Security #PickOfTheWeek
  Agentic AI systems have an existential security problem. This article explains the fundamental flaw: LLMs cannot reliably separate content from instructions. Learn practical mitigation strategies, like sandboxing agents and avoiding credentials in files, to eliminate at least one factor.
3. 5 rules to avoid the 95% AI project failure rate #PickOfTheWeek
  MIT research shows 95% of corporate AI pilots fail. The problem isn't the technology—it's transformation. In the article, you can find the 5 non-negotiables every C-suite needs to master for AI success.
Testing
1. Contract Testing Microservices with Pact: Ensuring Safe Deployments Across Teams
  Stop spending money on flaky end-to-end tests. This article shows teams how to use Pact to shift validation left. Understand the process of publishing consumer-generated contracts to a Pact Broker and how it provides a single source of truth for integration testing in distributed systems.
Leadership
1. 7 Quotes—7 Lessons
  Discover the hard lessons behind the humor, such as the need to check manager turnover before signing up and the danger of ignoring jerkholes, even if they are top performers.

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

2025-10-29T02:00:00.000-07:00

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.

Domain Types

Domain-Driven Design divides domains into three categories:

Core domains
Supporting subdomains
Generic subdomains

This distinction highlights that domains differ in both complexity and business importance.

Core Domains

Core domains are the primary reason we create a given solution in the first place. This is where we aim to gain an advantage over competitors — to be better, faster, or more efficient (whatever that means in a particular business context).
To identify your core domains, ask yourself:

What is the main problem our application solves?
What do we want to achieve by building this solution?
Why should customers choose our solution over the competition?
What do our customers get from us that they won’t get elsewhere — at least not with the same quality?

Generic Subdomains

These are all the areas of your business or application that are necessary but not differentiating. They don’t need to be better or different from what your competitors have. Ideally, you should buy or reuse existing, proven solutions instead of building them from scratch.

Supporting Subdomains

Supporting subdomains sit between core and generic domains. They contain requirements that cannot be fulfilled by existing software, so you must develop them yourself. However, they don’t directly create business advantage — they support your core domains in doing so.

Domain vs. Subdomain

In the categorization above, you might notice the use of the word domain for core, and subdomain for generic and supporting. To be precise, they’re all domains — areas of knowledge with their own boundaries and ubiquitous language.
The term subdomain is used next to generic and supporting categories to emphasize their lower business importance. The core domain and everything within its boundaries are the most crucial parts of your business. You should invest most of your time and energy in improving them so your competitive advantage grows over time.

(Sub)Domain Types Are Local

Categorization within your business, even if done correctly, is not universally valid. Something that is a generic subdomain for you (e.g., invoicing in a training center) might be a core domain for someone else (e.g., invoicing in an accounting system).
It gets more complex when the categorization differs within the same business. For example, in a training center, one group of stakeholders might want to compete with a rich offer and attractive pricing (making Sales the core domain), while another might aim to provide the best-quality training (Education domain).

How Many (Sub)Domains Can You Have?

You can have as many domains in each category as needed — there’s no strict limit.
There’s also no required minimum. If there are no generic or supporting subdomains, that’s perfectly fine, though it’s hard to imagine a project without at least one core domain.
Even in internal projects or those driven by regulatory needs rather than competition, there’s always a main reason for the project’s existence. Once you identify it, you’ve found your core domain(s).

(Sub)Domain Categories Can Change

Projects evolve, and so can your categorization:

A generic subdomain can become supporting when you start adding more business-specific logic.
A supporting domain can become generic if an external solution later fulfills your needs.
A supporting domain can turn core if you discover it offers potential business advantage.
A core domain can become supporting when your business model shifts and you stop investing in that area.

Can a generic domain become core, or vice versa? Over time — yes. Market changes force adaptation, and many companies have gone through such transformations. Rapid shifts are less likely but still possible, often triggered by major market disruptions that require fast and fundamental business adjustments.

Example: Training Center

Let’s revisit the domains we identified earlier.

The key question is: how can we differentiate ourselves from competitors? Where can we build our advantage?
In a real project, stakeholders must answer this question — it’s not a technical choice. Still, the answer will strongly influence our architectural decisions later.

In our example, we assume we want to offer the best-quality trainings on the market. They don’t have to be the cheapest, but customers should know they’re getting exceptional value for their money. Additionally, we want to help customers choose the best training for their needs — whether they are individuals or companies.
Based on this, both Education (high-quality training) and Sales (customer support in choosing) are our core domains.

Which areas can be covered by existing solutions?
From our analysis, GDPR, Archiving, Logistics, Calendar, and Accounting appear to be generic subdomains — we don’t need anything extraordinary there, so off-the-shelf products should suffice.

Finally, since our core domains are Education and Sales, it makes sense to classify Marketing, Customer Relationship Management, and Human Resources as supporting subdomains. We could validate whether external tools can help, but since our focus is on training quality (HR supporting skilled trainers) and building great offers (Marketing and CRM), this classification makes sense.

Summary

Today, we identified and categorized the domains in our training center. We now understand which areas are most important and deserve our time, money, and attention — and which can be bought or outsourced without harming our business.

Next time, we’ll explore how this classification helps shape software architecture and team organization.
In the meantime, feel free to ask questions if you’d like to dive deeper into any aspect of domain types.

Link Dump #212

2025-10-24T01:00:00.000-07:00

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

Software Architecture
1. Event-Driven Chaos Engineering: From Failure to Resilience in Kubernetes
  Event-driven chaos in Kubernetes ties alerts to automated failure tests, transforming unexpected disruptions into resilience by design.
2. The Hidden Architecture of Words — Ubiquitous Language Uncovered #PickOfTheWeek
  In this series, we explore Ubiquitous Language — how the words we use reveal boundaries, clarify meaning, and guide system design. Follow along as we move from theory to real-world examples and see how shared language turns chaos into clarity.
3. Reverse Engineering your Software Architecture with Claude Code to Help Claude Code
  This article shows how the author used an AI agent, Claude Code, to reverse-engineer full, end-to-end architecture flows spanning multiple repositories. The goal: to create clear, Mermaid-formatted documentation that helps both humans and other AI agents better understand the system's behavior.
4. Event-Driven Architecture in Monoliths: Incremental Refactoring for Java Apps
  Think event-driven architecture (EDA) is only for microservices? Think again. This article shows how implementing EDA within a monolith immediately reduces the rigid coupling caused by direct method calls. Discover how to create more testable and flexible code without the operational complexity of a distributed system.
5. Dealing with Race Conditions in Event-Driven Architecture with Read Models #PickOfTheWeek
  Stop fighting the chaos in distributed systems. This article advocates for a pragmatic approach: store data as it arrives and 'denoise' in your projections. Learn how to define read models with optional fields to handle partial state and make decisions based on available data, enabling reliable systems on unreliable foundations.
Software Development
1. Infrastructure as Code, Security Blind Spots, and the Messy Reality of DevOps #PickOfTheWeek
  This article argues that success depends on respecting human behavior and limitations. Learn why the secure path must be the easiest path, or engineers will inevitably bypass complexity to solve the immediate crisis.
2. Level Up Your Engineering Workflow with Copilot Templates
  Templates help you write cleaner code faster by converting repetitive patterns to reusable prompts. Copilot can streamline test generation, reduce manual effort, and accelerate productivity.
Testing
1. Testing the untestable #PickOfTheWeek
  In this post, the author shows how one can test legacy code not built on Dependency Injection.
2. Black Box vs. White Box Pen Testing: Which One Is Right for You?
  This article breaks down the fundamental trade-off: Black Box testing provides realism by mimicking an external attacker but is slow and may miss internal flaws, while White Box testing offers comprehensive coverage with full access but costs more upfront.

The Hidden Architecture of Words — Ubiquitous Language Uncovered

2025-10-22T01:00:00.000-07:00

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.

Here’s the complete series:

Ubiquitous Language — Boundaries, Words, and the Hidden Cost of Ignoring Them
Why language matters, how it shapes your domain model, and what happens when teams use the same words for different things.
Speaking Many Languages in One System
How to recognize that your system already contains multiple languages — and how these signals help you uncover natural domain boundaries.
Ubiquitous Language in Action: Boundaries Made of Words
A practical look at applying these ideas in the Training Center domain, showing how analyzing terms and events reveals where domains begin and end.

Together, these posts form a concise journey through Ubiquitous Language — from concept to discovery to practice.

If you’ve ever built software where business and developers “speak different worlds,” this series will help you find the words that bring them together.

👉 Explore the series and see how shared language can turn communication into one of your strongest design tools.

Link Dump #211

2025-10-17T01:00:00.000-07:00

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

Software Architecture
1. Ubiquitous Language in Action: Boundaries Made of Words #PickOfTheWeek
  Have you ever noticed how the same word can mean completely different things depending on who says it? In this article, we dive into the Training Center domain and discover how boundaries shape the language we use — and how they sometimes hide the real meaning behind familiar words.
Software Development
1. Developer Experience: Overcoming 6 AI-Induced Challenges
  AI tools promise to boost developer productivity, but a recent study found they can actually increase task completion time by 19%. This article explores the six unexpected challenges AI introduces to Developer Experience (DevEx), from tool fragmentation to latency bottlenecks, and offers practical mitigation strategies.
2. Prioritizing Software Quality Requirements
  You can’t have the maximum value for all quality characteristics. Read the article to learn how to decide which are most critical.
3. Operationalizing Responsible AI: Turning Ethics Into Engineering #PickOfTheWeek
  This article will provide a direction on how to build a reliable AI system in production by incorporating bias mitigation strategies.
4. Why context engineering is like teaching AI to skip stones #PickOfTheWeek
  Discover why overloading an LLM with every possible fact is less effective than curating and routing only the most relevant, actionable context at the right time.
Testing
1. What is API Testing?
  Learn what an API is, its different testing types, tools, and benefits to improve software quality and reliability.
Leadership
1. From Confusion to Clarity: How RACI and DACI Can Help You Prevent Decision Paralysis #PickOfTheWeek
  Learn what RACI and DACI matrices are and how these deceptively simple tools transform how teams make decisions and execute work.
Growth
1. To-Do or Not To-Do
  Is your to-do list a source of frustration, not completion? This article argues that the problem isn't knowing what to do, but reserving the time to do it.

Ubiquitous Language in Action: Boundaries Made of Words

2025-10-15T01:00:00.000-07:00

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.

Where were we?

After our last Big Picture Event Storming session, we ended up with a lot of information, shared understanding, and a significant amount of knowledge:

Let’s take a closer look at it and apply one by one the hints we learned last time to gain deeper insights into the business.

Look for domain experts around you

Let’s go through some events to identify our domain experts:

Some events are related to the training program—its creation and future improvements. The person who can tell us more about building it is the trainer (education domain).
The trainer is also a domain expert when it comes to conducting training (education domain).
After creating the program and before conducting training, we need to sell it. Here, the Sales team can explain the nuances of this process (sales domain).
Once the training is confirmed, it must be organized. Who would know more about that area than the logistics department? (logistics domain)

In this way, we increase our understanding and collect details that help us establish domains and the language within their boundaries. We might already have some ideas, but remember: the amount of detail within a domain can be a good indicator of whether to divide it further. We’ll leave that step for later.

Of course, these aren’t all the domain experts we can identify based on the events we placed on our virtual wall. I encourage you to find more on your own and share your observations in the comments.

⚠️ Warning: Don’t confuse participants with experts

Remember: a person involved in an event (either initiating or reacting to it) isn’t necessarily a domain expert. For example, someone searching for training for themselves (a Customer) isn’t an expert in this area—they don’t prepare our training catalog. Here, the domain experts are the trainer (who creates and conducts the training) and someone from the Sales department (who builds an offer attractive to customers).

⚠️ Warning: Use roles, not names

It’s better to name your domain experts by their roles, not their actual names. Why? Because sometimes a single person or department can be responsible for more than one domain. Using role names increases your clarity and prepares you for future organizational growth.

Same word, different meaning

Let’s look at some of the events we found so far:

We have two events referring to resources, but since they belong to different domains, their definitions differ:

Resource (logistics domain): a trainer, classroom, or piece of equipment needed to deliver a course.
Resource (education domain): learning materials—slides, videos, or readings shared with participants.

As you can see, one refers to a person or a place, the other to content. Until we assign them to their respective domains, they remain ambiguous. Once the domain is clear, their meaning becomes obvious.

⚠️ Warning: Verify meaning differences with experts

Always validate with domain experts whether certain words truly have different meanings. Sometimes we unintentionally “merge” words with meanings borrowed from their context:

In one case, we refer to a training agenda, and in another to a meeting agenda. There are differences between them (length, topics, purpose, etc.), but those come from the difference between training and meeting. The definition of agenda itself remains the same—a plan of things to do or discuss.

Also, note that this distinction tells us nothing about domain boundaries. Both events (Training Agenda Set and Meeting Agenda Shared) could belong to the same domain or to two different ones. The word agenda alone indicates nothing in this case.

Same word, different characteristics

Let’s look at several events related to Training:

Even though the word training appears in each event, we should validate whether it represents the same concept in all cases:

Training Ordered: here, the training is a product to sell and buy (sales domain).
Training Scheduled / Conducted: here, the training is an event to organize, with a beginning and an end (logistics domain).

This step is easier when domain experts have already been identified. Their perspectives help us see the same event through different lenses.

Same data, different names

This time, things get trickier. Let’s look at these examples:

Training and webinar share many similarities but also many differences. Yet, if we look at this specific events, both involve a common subset of data: what is scheduled, when, for whom, and where. Looking at these details, this seems like an Event (scheduling domain). If we later need to coordinate such events—for example, to verify trainer or sales availability—it might make sense to introduce a separate Scheduling domain.

⚠️ Warning: Don’t overcomplicate the model

Always validate with domain experts whether creating a new domain or concept is justified. Our goal is to understand the business better and make systems simpler—not add unnecessary complexity just because we can.

Same person, different name across the process

Let’s analyze the person registering for a training. The same individual is called differently at various stages:

Customer: exploring our offer (sales domain).
Payer: confirming their purchase (accounting domain).
Recipient: receiving payment confirmation and training details (notification domain).
Participant: attending the training and learning (education domain).

Same item, different name across the process

A similar pattern applies to non-human entities, like invoices:

Invoice: generated when someone pays for a training (accounting domain).
Attachment: when sent to the payer via email (notification domain).
Document: when archived for legal reasons (archival domain).

No interactions and no consistency

Some events clearly don’t belong in the same domain:

Training's Fee Paid: a payment for training (accounting domain).
Conference Talk Given: a talk delivered at a conference (education domain).

It’s hard to find a logical link between these two. There’s simply no shared context.

⚠️ Warning: Missing knowledge may hide connections

The fact that you can’t connect two events doesn’t mean a connection doesn’t exist—it might simply be hidden due to missing knowledge. Validate this with domain experts. Either they’ll confirm there’s no link, or you’ll learn something new about the business.

Putting it all together

The level of detail often determines whether a domain should be split. After walking through all these hints, we can now decide what domains we have. Don’t worry if later you realize some are too broad and need splitting, or too narrow and should be merged. That’s normal—it reflects learning and refinement over time.

Name your domains (if you haven’t yet)

Identifying domain boundaries is one thing; naming them is another. I encourage you to name each domain as soon as you identify it using today’s heuristics. This helps continuously validate whether your boundaries make sense.

Every piece of information belongs somewhere

After applying all heuristics, many events will already be placed within clearly defined domains. Yet, some may still remain unassigned. It’s important to place every piece of information into a domain, as this validates your overall structure.

⚠️ Warning: When no domain fits

Sometimes, an event won’t fit any existing domain. In such cases:

Option 1: place it in the closest group and adjust the domain name if needed.
Option 2: create a new domain.

Which option to choose? It depends on how far the event diverges from others. If it’s only a subtle difference, adjust the name of the domain and add event to it. If it’s fundamentally different—create a new domain.

⚠️ Warning: When event fits multiple domains

You may encounter disagreements on which domain an event belongs to. Sometimes, this means the event should appear in both. That’s fine.

Consider our earlier example:

During our workshop, an event might be written simply as Agenda Set. When assigning it to domains, we may realize it makes sense in more than one place. Just copy it and place it in both domains.

⚠️ Warning: Duplicates may signal new domain

If you find similar group of events duplicated across domains, and they have minimal (or no) differences, this might indicate the need for a new domain. Duplication often signals underlying complexity worth isolating.

Shape of domains in the Training Center

Let’s combine everything we’ve learned and look at the domains within our Training Center:

Summary

Today, we started with the outcome of the Big Picture Event Storming session and ended with clearly defined domains and unambiguous language. Making it truly ubiquitous will take time, but we’re on the right track. We now have a better understanding of the business and can communicate more effectively.

Now, take a deep breath—it’s time to prepare for the next step.

Link Dump #210

2025-10-10T01:00:00.000-07:00

Friday is the perfect day for the reading mood:

Software Architecture
1. Breaking Down Monoliths: Strategies to Refactor Legacy into Microservices
  This article walks through the reasoning behind breaking a monolith, the strategies that work in practice, and the challenges you should expect along the way.
2. The anvil of alignment: The value of monoliths over microservices #PickOfTheWeek
  Before dismantling your monolith for microservices, understand its crucial role in organizational alignment. We explore hidden costs, Conway's Law, and strategic insights for leaders making architectural decisions.
3. Microservices Madness: Practical Patterns That Keep Your Services Resilient
  Is your microservice architecture a headache waiting to happen? This article cuts through the chaos with five practical resilience patterns. Learn how to use Circuit Breakers to prevent cascading failures and Bulkheads to ensure one service overload doesn't sink the entire system.
Software Development
1. Build vs. Buy: What it Really Takes to Harden Your Software Supply Chain
  This article urges teams to assess what they can sustainably support over time, covering the four areas where complexity hides: continuous CVE response, automation upkeep, integration testing bottlenecks, and securing the image distribution.
2. Speaking Many Languages in One System #PickOfTheWeek
  Ubiquitous Language only works if we respect its boundaries. Once words start shifting meaning—like customer → payer → recipient—we’re no longer in one domain but crossing into another. In my latest article, I share simple heuristics to spot these boundaries and make your software language consistent and clear.
3. Beyond the Mess: A Complete Look at Event Storming Big Picture #PickOfTheWeek
  Big Picture Event Storming can look messy, but it’s designed to create clarity. In this series, I share how to start, manage chaos, sequence events, overcome challenges, and turn sticky walls into action. A complete guide for anyone who wants better collaboration between business and tech.
4. Machine Learning vs Deep Learning vs Generative AI
  This article explored Machine Learning vs Deep Learning vs Generative AI, highlighting their core concepts and differences.
5. Ask a Techspert: What is vibe coding?
  This article breaks down how this AI-powered method allows users to translate an idea into a functional design. Learn how you can improve your results by refining your prompts in a chat tool first to develop 'taste' and lead the AI process.

Speaking Many Languages in One System

2025-10-09T01:00:00.000-07:00

Last time I explained what Ubiquitous Language is, why it is crucial to use it, and how it can support software evolution and maintenance. Today, I would like to share several approaches that can help you define the boundaries of domains within your application.

What Ubiquitous Language Is – A Quick Reminder

Ubiquitous Language exists only within clearly defined boundaries. Inside those boundaries, it remains consistent (terms fit together logically) and unambiguous (each word has exactly one meaning).

How We Can Identify Domain Boundaries

Every piece of software contains domain knowledge. It may not yet be documented or expressed in code, but it is present. Words, phrases, and interactions exist, waiting to be explored and understood in depth. However, this knowledge often lacks boundaries, which is why it can be misleading, ambiguous, and misinterpreted.

Fortunately, those very words and terms can help us discover and clarify domain boundaries. Several language-driven heuristics can support this exploration.

Look for the Domain Experts Around You

When building software, you collaborate with many people who help you understand what needs to be created. Some provide requirements, others support delivery. It is valuable to ask yourself whether these people come from the same area of expertise.

For example, imagine you are opening a shop. You will need to interact with many individuals. Even though the shop unites them under one business, they may live in very different “worlds,” using distinct language and specialized knowledge—for instance, an accountant, a marketer, or someone responsible for product assortment. Although the business connects them, the knowledge they possess belongs to different ubiquitous languages.

Same Word but Different Meaning

Take the word “date”. Its meaning depends on context: it could represent a calendar point in time, a romantic meeting, or even a fruit. Without clear boundaries, the word is ambiguous.

When examining your software’s domain knowledge, encountering such words is a strong indicator that they belong to different domains. Do not attempt to eliminate them by using synonyms. If the word is valid in a given context, keep it—just separate it across domain boundaries.

Same Word with Different Characteristics

The word “characteristics” can describe data, interaction, or both. Different experts may look at the same thing but from different perspectives. Consider an apartment:

The Architect
Perspective: Focuses on design and structure.
Language: Abstract and technical (e.g., floor plans, load-bearing walls, zoning).
Difference: Describes the blueprint, not daily use.
The Decorator
Perspective: Focuses on aesthetics and interior functionality.
Language: Artistic and stylistic (e.g., color palette, focal points, furnishings).
Difference: Concerned with visual appeal, not construction.
The Tenant
Perspective: Focuses on lived experience.
Language: Practical and personal (e.g., rent, storage space, natural light).
Difference: Sees the apartment as a home, separate from design or decoration.

Even though they all refer to the same apartment, each perspective belongs to a different domain. Within one domain expert’s perspective, the language is cohesive, but when you move to another expert, the terms and understanding change significantly.

When exploring a business domain, you may encounter such experts. Even if you cannot identify them immediately, analyze the language: does the same phrase always mean the same thing? If not, you may be dealing with different domains.

Same Data, Different Names

Another signal of multiple domains is when the same data set is described differently depending on context. For example, consider a work activity described by: description, assignee, due date, and status. From a project management (domain) perspective, it is a Task—a unit of work in an iteration. For IT support (different domain), however, the same data is referred to as a Ticket.

Same Person Named Differently During a Process

Consider an online shop. A person browses products, makes a purchase, and receives delivery. Throughout this journey, the same person is referred to differently:

Customer in the sales domain, when browsing and intending to purchase.
Payer in the payment domain, when completing the order.
Recipient in the shipping domain, when the goods are delivered.

Even though it is the same person, each step belongs to a different domain with its own terminology.

Same Item Named Differently During a Process

Similar to the previous example, but this time applied to items rather than people. In an online shop:

Item in the shipping domain, where focus is on dimensions, weight, and handling.
Product in the sales domain, where marketing details and attributes matter.
SKU (Stock-Keeping Unit) in the inventory domain, where storage location and cost are key.

No Interactions and No Consistency

A hallmark of ubiquitous language is consistency: words should fit together and reinforce one another. If terms do not work together coherently, it suggests they may belong to different domains. This indicator, however, can be tricky—sometimes the missing link is simply a gap in understanding. Use it cautiously and as a last resort.

For example: castle, pen, hugging. Do you see them forming a consistent domain? Probably not.

You Need Domain Experts

The hints shared above are powerful tools to analyze language and enclose it within clear domain boundaries. Still, it is essential to include domain experts in this process. As developers or architects, our knowledge often only scratches the surface, and without expert input, we risk making poor decisions due to incomplete understanding of the domain’s complexity.

Where Can You Find Input for This Exercise?

We have already discussed Event Storming Big Picture as a technique to uncover domain knowledge and collect terminology useful for defining boundaries.

But if Event Storming is not an option (though I highly recommend it), you can use other inputs:

Documentation
Requirements
Backlog tasks
Conversations and Q&A
… and many more

In fact, any artifact or activity that expands your business-related vocabulary is valuable. Pay special attention to nouns and verbs, as they are particularly effective for domain exploration.

Summary

Businesses often come with rich, complex, and unfamiliar vocabularies that can feel overwhelming. Ubiquitous Language is a tool to tame this complexity and make it manageable. The techniques and heuristics shared today should help you apply it more effectively and gain greater benefits from it.

Beyond the Mess: A Complete Look at Event Storming Big Picture

2025-10-07T01:00:00.001-07:00

Over the past months, I’ve been exploring one of my favorite collaborative techniques – Event Storming Big Picture. It’s a powerful way to untangle complexity, discover hidden assumptions, and build a shared understanding across business and tech. Instead of explaining everything in one go, I decided to create a series of posts that walk you through the practice step by step.

Here’s the full series:

1. Navigating the Storm: A Guide to Big Picture Event Storming

Why run a Big Picture workshop and what you get from it. Introduces the building blocks and main steps, plus tips on when to use chaotic exploration vs timeline.

2. Taming the Storm: How Chaotic Exploration Leads to Clarity

Using the Training Center domain, shows preparation, event discovery with stickies, and de-duplication. A clear example of turning chaos into insights.

3. Event Storming Big Picture — How to enforce the Timeline?

Explains the timeline phase: draw it, pick a starting point, keep discussions focused, and move leftovers to hot spots. Sequencing helps reveal interactions.

4. So… Which Event Goes First?

Shares three strategies to start the timeline: pick any event, one-per-person, or voting. Each has pros and cons but gets the wall moving.

5. Big Challenges of Event Storming Big Picture

Covers common pitfalls: losing sight of goals, poor time use, dominant voices, or empty walls. Offers facilitator tips to keep value high.

6. After the Big Picture: Turning Insights into Action

Explains how to use the wall: assess risks, propose service boundaries, and choose next processes to explore. Big Picture is a starting point, not the end.

Taken together, these posts form a complete journey through Big Picture Event Storming – from the first sticky note to actionable insights. My hope is that they give you both the confidence to try it and the practical tools to succeed.

If you’ve ever struggled with messy domains, miscommunication between business and IT, or unclear priorities, this series is for you.

👉 Dive in, explore the posts, and let me know which part of the storm resonates most with your work.

Link Dump #209

2025-10-03T01:00:00.000-07:00

Coffee and something to read - day cannot start better than that.

#BookOfTheMonth
Introducing Event Storming
Software Architecture
1. The Design System Team: Goals, Pains, and Successes
  Starting or scaling a design system? This article offers practical insights into the common goals, such as defining design tokens and ensuring all components are accessible. It also touches on the major pain point: managing visual and user experience inconsistencies during a gradual, horizontal migration away from legacy components.
2. Building a Resilient Data Platform with Write-Ahead Log at Netflix #PickOfTheWeek
  Netflix built a Write-Ahead Log (WAL) abstraction to tackle critical data challenges like accidental data loss, system entropy, and unreliable retries. Discover how this distributed system provides strong durability guarantees and ensures data consistency across diverse datastores.
3. How to Build Real-Time Alerts to Stay Ahead of Critical Events #PickOfTheWeek
  This article explains the shift from monitoring dashboards to proactive, real-time alerting. Discover how using Apache Kafka and data streaming enables you to detect critical events—like fraud or system anomalies—in seconds and trigger automated responses before issues can escalate into financial or reputational damage.
4. Do Microservices Need Event-Driven Architectures? #PickOfTheWeek
  The shift to EDA isn't just technical—it's a business advantage. This article shows how event-driven microservices translate to faster innovation cycles, reduced downtime risk through fault isolation, and more responsive customer experiences.
Software Development
1. Capability Mapping: The Bridge Between Strategy and Reality #PickOfTheWeek
  This article introduces Capability Mapping as the essential bridge, providing a common visual language to link high-level business goals with the underlying technology and processes. Learn how this powerful tool brings strategy down to reality.
2. Secure MQTT Implementations – TLS, Authentication, and Access Control for IoT Networks
  This article explores how to secure MQTT deployments with TLS encryption, authentication mechanisms, and fine-grained access control, providing a practical roadmap for building resilient IoT networks.
Leadership
1. How to Coach Yourself Through Complex Problems
  Leaders today are facing more complexity, faster change, and higher expectations than ever. But budget cuts, approval bottlenecks, and cultural barriers can put the executive coaching that could help them navigate all this uncertainty out of reach. This is where self-coaching can come in.
Fun
1. Property Flippers

Link Dump #208

2025-09-26T01:00:00.000-07:00

How about an article on Friday? Or two, three, ...

Software Architecture
1. Hexagonal Architecture Explained: Why It’s Not Just Another Buzzword
  In this article, the author breaks down what Hexagonal Architecture is, why it matters, how it compares to other architectures, and shows real-world examples of applying it effectively.
2. Unified Checkout Experience Through Micro Frontend Architecture
  Learn about the architecture and design for building a scalable end-to-end product that can integrate front-end apps to provide a cart and payment services.
Software Development
1. Top five data modernization strategies for business success #PickOfTheWeek
  Data modernization isn't just about technology—it's about driving business outcomes. Discover how to gain executive buy-in and create a feedback loop that ensures your data initiatives deliver measurable value.
2. Domain-Driven Design in the Real World: Lessons from Large Projects #PickOfTheWeek
  In this article, the author walks through lessons learned from applying DDD in substantial projects, showing where it excels, where it stumbles, and how to adapt it pragmatically.
Languages and Frameworks
1. Memory Usage Optimization In Spring Boot
  In this example, the author examines ways to reduce memory usage without impacting application functionality.
2. Critique of JEP 505: Structured Concurrency #PickOfTheWeek
  Java 25 introduces a preview of structured concurrency, but is the design flawless? This article offers a critical look at JEP 505, highlighting problems like non-uniform cancellation and the split between a scope's logic and its Joiner. Discover the "rough edges" that could impact real-world applications.
Agile
1. Applying Agile & Hybrid Frameworks in Large Projects #PickOfTheWeek
  Succeed in a hybrid Agile-Waterfall world. This article offers practical advice on how to align milestones, provide dual visibility in reporting, and push for incremental validation in complex projects. Equip yourself with the knowledge to keep your large team aligned and focused on delivering strategic business goals.
2. Agile Is Both Iterative and Incremental
  This article explains how combining iterative refinement and incremental delivery allows teams to provide value early, gather feedback, and adapt their plans, leading to more responsive and valuable outcomes.
Leadership
1. Confront the lies of comfort
  This article offers seven actionable ways to resist the 'seduction of comfort,' including bringing up issues others avoid and asking, 'What would you like to do about that?' Equip yourself to provide support without validating inaction and to confront problems head-on.
2. 5 Benefits of Over-Commitment #PickOfTheWeek
  This article challenges the conventional wisdom, arguing that a period of 'overload' can act as a crucible for aspirational leaders. Discover how pushing your limits can reveal untapped strengths and expose your true motivations.
Fun
1. Identify a Nap