This episode is brought to you by IcePanel, a collaborative diagramming and modeling tool for architects. Model your system from business context down to components, keep diagrams in sync automatically, and connect your architecture to your favorite LLM via their MCP server. Try it free: icepanel.io/luca

In this episode of Dear Architects, Luca sits down with Chris Richardson, author of Microservices Patterns and the creator of microservices.io, for a wide-ranging, no-hype conversation about where microservices actually stand in 2026, and what Gen AI does (and doesn't) change about how we design systems. Chris and Luca dig into why so many organizations still end up with a "distributed monolith," the real warning signs of bad service boundaries (hint: watch your services-to-developer ratio), and Chris's own framework for deciding what belongs together and what should be pulled apart — the Dark Energy and Dark Matter forces. They also get into the social-technical side of architecture: why team topologies, DevOps, and org structure matter as much as the diagrams, and why "the architecture is bad" is often just a symptom of deeper organizational issues.The second half turns to AI: the guardrails that actually make coding agents useful (tests, pre-commit hooks, code scanning), why brownfield modernization is nowhere near as simple as greenfield demos suggest, why Chris still prefers the Strangler Fig pattern over "big bang" AI rewrites, and a healthy dose of skepticism about the claims flooding your LinkedIn feed.If you're an architect, tech lead, or engineer trying to figure out what's signal and what's noise in the current AI moment — this one's for you.

Chapters

00:00 Intro

01:36 Welcome, Chris Richardson

03:15 Chris's career: testing, Spring/Hibernate, the cloud, Cloud Foundry

06:01 State of microservices in 2026

07:30 "Living systems" — why boundaries need constant reassessment

09:47 Software serves two constituencies: users and the organization

10:19 Team topologies, DevOps, and the success triangle

12:53 Holistic engineering

13:36 The "red flag law" anti-pattern

14:51 Warning signs: the services-to-developer ratio

16:41 System releases and the distributed monolith trap

17:41 Service boundaries in practice

18:18 Default to monolith unless there's a clear problem to solve

19:03 Dark Energy & Dark Matter: the forces behind service boundaries

23:00 Dark Matter forces: runtime coupling, ACID vs. BASE

24:44 Collocating code isn't a weakness signalr

26:25 Ten forces, weighted by your own context

28:16 Architecture serves the organization, not just the customer

29:20 Latency-sensitive endpoints and selective distribution

31:31 AI hype: "we rebuilt it in 48 hours"

33:43 Best practices matter more, not less, in the Gen AI era

36:05 Multi-agent architectures and inter-service communication

37:33 The "agents for everything" trap

39:29 "SaaS is dead"? Big tech hype and bubble skepticism

40:26 Brownfield vs. greenfield: the AI modernization gap

42:02 Guardrails that work: tests, pre-commit hooks, code scanning

43:14 Legacy code without tests meets a probabilistic system

44:24 Human accountability for AI-generated code

45:22 Where architecture fits in the AI era

47:21 What AI-driven modernization gains — and loses

50:04 Strangler Fig over the "big bang" rewrite

53:36 Spec-driven development: waterfall in disguise?

54:16 Why well-documented systems are easier to AI-rewrite

56:02 "We are all juniors again"

57:55 Fundamentals over hype: modularity and loose coupling

59:47 AI burnout and the "slot machine" effect

1:01:26 Juniors, hiring, and whether Gen AI is even a profitable business

1:05:04 Final advice: the architectural mindset

1:07:21 Wrap-up and thanks

subscribe to Dear Architects: https://deararchitects.xyzWhen companies grow through acquisition, architects inherit a mess: multiple teams, different engineering cultures, conflicting tools, and no shared map of the system. In this episode of Dear Architects, Luca sits down with Mahdi, tech leader at Fashion Cloud, a B2B wholesale platform connecting brands and retailers. Mahdi shares the in-the-trench story of how Fashion Cloud is rationalizing a federated socio-technical system after multiple acquisitions, starting bottom-up rather than top-down. They cover where to begin when you have fragmented teams under one CTO, how strategic Domain-Driven Design helps separate common platform capabilities from product-specific verticals, why the C4 model became their visualization backbone, how IcePanel replaced Miro for living architecture documentation, the role of ADRs and RFCs in capturing decisions, and how they handle cross-cutting concerns without killing team autonomy. Mahdi also shares how Fashion Cloud is experimenting with AI in their architecture practice, and the one piece of advice he wishes he'd given himself at the start of the transformation. If you're navigating a post-merger integration, modernizing a hybrid system, or just trying to build an ownership culture in your engineering org, this conversation gives you a practitioner's playbook.Chapters00:00 Intro and meet Mahdi from Fashion Cloud00:51 What is Fashion Cloud and the post-acquisition challenge06:40 Where do you start with multiple teams under one CTO13:39 The bottom-up approach: ownership without the architect title17:19 Strategic DDD: common platform vs product verticals21:43 Was it worth it? Reflecting on the transformation26:31 Visualizing systems: why the C4 model30:53 From Miro to IcePanel: choosing the right tool35:39 Architecture Decision Records and capturing the why44:19 Driving adoption: getting buy-in across the org45:19 Handling cross-cutting concerns in a federated model50:35 Building an ownership culture, not enforcing it51:39 AI in architecture practice: what actually works57:59 Advice to your past self58:55 Key takeaways and wrap-up

What does it take to go from answering support calls in a small town in northern England to advising some of the largest companies on the planet at AWS and then becoming a developer advocate at Datadog? In this episode, I sit down with James Eastham to unpack a career built entirely in the trenches, without a traditional computer science background and without a straight path.We go deep on the real turning points: the crushing imposter syndrome of joining AWS ProServe, the "Magpie syndrome" trap of chasing shiny technology over context, and the moment every architect hits when they realise there is no right or wrong, only trade-offs.James shares a powerful reframe of imposter syndrome as a signal of growth, a practical habit for improving architectural decision-making, and a frank warning about what vibe coding and AI-assisted shipping will do to teams that skip the design thinking.We also get into the broader AI question: LLMs as amplifiers and why context, attitude, and fundamentals are the only things that truly compound over time.

Subscribe to the newsletter: https://deararchitects.xyz📚 RESOURCES MENTIONED📖 Architecture for Flow — Susanne Kaiser: https://amzn.to/4bMl0UR📖 Team Topologies — Matthew Skelton & Manuel Pais: https://amzn.to/3NIESA9📖 Wardley Mapping: https://www.wardleymaps.comIn the age of AI-accelerated development, most teams are shipping faster than ever but faster into the wrong direction. Investing time in software design, team alignment, and architectural thinking is not slowing you down. It is the only thing that will stop AI from amplifying your existing bottlenecks at scale.In this episode of Dear Architects, Susanne Kaiser, author of "Architecture for Flow," shows how to combine Wardley Mapping, Domain-Driven Design, and Team Topologies into a single coherent approach, in this way your architecture, your teams, and your business strategy finally move in the same direction.We get into what fast flow really means, why Conway's Law shapes your software whether you acknowledge it or not, how event storming becomes your most powerful tool in the AI era, and whether the "Architect" job title will even exist in the future.🕐 CHAPTERS0:00 Intro & meet Susanne Kaiser2:10 Why Susanne wrote Architecture for Flow5:10 What is fast flow (and why friction is a signal, not a problem)9:00 Conway's Law & the sociotechnical system12:40 Wardley Mapping explained15:00 Using Wardley Maps with leadership and the C-suite19:20 How Susanne approaches a new client engagement22:30 Domain-Driven Design: bounded contexts & subdomains24:20 Event Storming: where to start and how to run it31:10 Keeping event storming as a living document33:30 Team Topologies: the missing puzzle piece38:00 How team types map to bounded contexts41:00 Team interactions and how they evolve over time42:30 Systems are living — not just code43:30 The Architecture for Flow Canvas46:00 How long does the canvas process take?47:40 Evolving your North Star (not a big upfront design)50:30 AI accelerates your bottlenecks — not just your delivery54:00 Why DDD and event storming matter more in the AI era56:20 Architecture Decision Records and institutional memory58:30 Will the "Architect" job title disappear?1:01:20 The architect as coach: a federated future1:02:30 Where to start if you want to try this today1:04:00 Wrap up & where to find Susanne

subscribe to the newsletter: https://deararchitects.xyzBalancing Coupling in Software Design: https://amzn.to/4rotZlzLearning Domain-Driven Design: https://amzn.to/4tGQvb2Most architects have been thinking about coupling the wrong way for years. Not as something to understand and design deliberately but as something to eliminate. That misunderstanding is behind most of the distributed monolith disasters of the microservices era.In this episode, Vlad, author of Balancing Coupling in Software Design, shares what he learned after building a textbook distributed monolith while following best practices to the letter. We dig into why coupling is unavoidable, what the three dimensions of coupling actually are, and why strategic DDD consistently beats tactical DDD for large systems.But the conversation takes an unexpected turn: Vlad argues AI is the third coming of Domain-Driven Design. When you prompt an AI in natural language, ambiguous domain models don't just slow your team down — they get baked silently into generated code. The same discipline that makes systems evolvable turns out to be the foundation for working effectively with AI.

0:00 Intro & guest welcome1:00 Why modeling is the foundation of good software design2:45 Rethinking coupling — it's not what you think8:00 How microservices created the distributed monolith trap14:00 The real cost of splitting without fixing the design19:00 Why pain is your best architectural signal23:00 Domain-Driven Design has a reputation problem28:00 Strategic DDD vs tactical DDD — what actually matters33:00 How to approach a brownfield system37:00 Subdomains: the hardest part of DDD nobody talks about enough41:00 Bounded contexts and why less is more for startups46:00 AI is the third coming of Domain-Driven Design52:00 Teaching DDD to an LLM — what Vlad actually tried55:00 Working code is no longer the challenge. Evolvable code is.1:00:00 What Vlad would change in his book1:07:00 What's next

subscribe to the newsletter: https://www.deararchitects.xyz

ACED model: https://jacquiread.com/posts/better-software-design

In this first episode of Dear Architects, Luca welcomes Jacqui Read, author of Communication Patterns, to explore why most software architecture problems aren’t technical, they’re communication failures.They dive deep into:

• Why architecture must be iterative (and why big upfront design fails)

• The dangerous return of waterfall thinking through AI and spec-driven development

• Why LLMs require better communication, not less• The gap between business and technical teams — and how to fix it

• The ACE model (Context, Design, Architecture, Engineering)• Living documentation, ADRs, and clear code vs “clean” code• Why most companies want automation — not AI

• How architects should evolve in the AI eraIf you think architecture is just diagrams and tech decisions, this conversation will change your perspective.

Because architecture isn’t about boxes and arrows.