A team can own an AI capability and still not own the decisions made inside it. As language models move from completing code to shaping the ubiquitous language, a meaningful share of a team's domain model decisions can be quietly made by an upstream the Context Map never draws. This post proposes a name for that blind spot, ghost ownership, separates it from Conformist, Shared Kernel, and Partnership, and offers a heuristic for how much of it each subdomain can afford.

A raw language model cannot give you a Published Language, because it cannot enter an agreement. It can answer in natural language structured by nobody, different on every call, and that is precisely what makes it an upstream Big Ball of Mud on your Context Map. This first deep dive in the Context Maps in the Age of AI series works through what it takes to put a boundary in front of that model: why every MCP server is an Open-Host Service commitment, and why the schema you expose is only the beginning of the Published Language you actually need.

Context Maps were never about IT systems alone. They were about sociotechnical systems: the teams, the politics, the influence between people who build models. AI introduces a new kind of actor to that picture, one that does not negotiate and drifts silently. This post opens a series that walks the whole Context Map catalog and asks, pattern by pattern, how they still hold up when a new actor is present.

Wanting a platform is not the same as having earned one. Organizations stand up a platform team and ship a v1, only to watch stream-aligned teams route around it. This post treats platform timing as a strategic decision in its own right. It offers signals that the timing is wrong, smaller practices to use before committing, and a portfolio framing that connects build, buy, and wait.

Every team agrees that small daily improvements are a good idea. Yet most teams never do them, because intentions are weak under pressure. This post applies the ideas behind James Clear's Atomic Habits to software teams and explores how 10-minute daily improvements, designed as team habits, compound into real architectural change over months and years.

Architecture strategy and procurement strategy are made by different people, at different times, with different incentives and almost never in conversation with each other. The result is a systematic destruction of the conditions that fast flow requires. This post introduces a framework combining DDD, Cynefin, and Wardley Maps to make better sourcing decisions including what AI delegation changes about the picture in 2026.

Bounded Contexts aren’t just about drawing boundaries, they’re about cohesion. This article explores how the classic idea of functional cohesion from the 1970s Structured Design paper connects directly to Domain-driven Design. By focusing on purpose as the organizing principle, we can design Bounded Contexts that form coherent, unified wholes, models that truly “stick together” in meaning, language, and intent.

This post reflects on a hands-on workshop conducted at DDD Europe 2025, where we meticulously examined six distinct strategies for persisting aggregates in Domain-Driven Design. We delve into the technical implications, advantages, and disadvantages of each approach – including Memento, JPA, Document Databases, Event Sourcing, and more – as collaboratively identified by the workshop participants. Expect a comprehensive analysis of the trade-offs involved, highlighting the crucial understanding that design decisions are context-dependent and that there is no universal "silver bullet" solution.

Platform Engineering is transforming how we build and deliver software. While technical platforms are crucial, they often overlook the complexities of business domains. This article explores the shift towards Business Domain-Centric Platforms. Discover why moving beyond technical foundations is essential for business agility and fast flow.

This post addresses the challenge of navigating the complexity of EventStorming workshops, specifically focusing on the identification of "Pivotal Events." It outlines a series of heuristics to help participants distinguish between routine events and those that represent significant business decisions, state changes, or downstream impacts. The article provides practical guidance for facilitating discussions and using these pivotal events to inform system design and domain understanding.

Fantastic final day at Agile Meets Architecture 2025! Great talks, amazing community vibe, and lots of inspiration, especially around AI and dynamic teaming from Jurgen Appelo. Sad it's over but leaving with a buzzing brain! Read my takeaways

Day 1 of Agile Meets Architecture in Berlin was a great start to a great conference. Catch my blog post for my personal highlights and insights!

Kick off as a freelance consultant