Strategic vs Tactical Platform Design

Domain-driven design splits design into two kinds of question:

• Strategic design clarifies the boundaries and how they relate. For a platform: where should we invest, and what should the platform’s boundaries be?
• Tactical design answers how we implement inside those boundaries: how we build a specific capability.

Most platform pain I’ve seen comes from answering tactical questions well inside strategic boundaries that were never drawn.

Tactical habits that work

Evolve from something simple that works. Gall’s Law: a complex system designed from scratch never works and can’t be patched into working; a complex system that works has always evolved from a simple one that worked.

Take small steps. Martin Fowler’s point about refactoring applies to platforms too: you go faster by taking smaller steps, keeping things working the whole time, and composing them into big changes. It’s the same principle as Progressive Overload and Incremental Migration.

Dogfood. If you provide pipeline capabilities, build the platform’s own pipelines with them. Nothing builds empathy for users’ pain points faster.

Cross-team chatter is an architectural bug

The book’s line is that cross-team chatter isn’t a collaboration feature, it’s coupling between contexts. Each team should know what it delivers and what it consumes, rather than depending on another team to get through the day.

My first reaction was: really? A UI team will always need the backend team when an API isn’t quite right, or to understand a requirement. Where I’ve landed:

• The APIs a team integrates with should be its documented interface, with formal contracts (Contract-Driven Development), so most of the time you already know what to build against.
• Bugs shouldn’t be shipped in the first place, and fixing them shouldn’t depend on someone from another team.
• The chatter that’s left is a signal: a missing contract, or a boundary in the wrong place. Worth fixing, not just tolerating.

A quick readiness check

Before going strategic, ask: are our context boundaries well defined? Have we classified capabilities by how domain-specific they are? Does the platform speak domain language (Ubiquitous Language for Platforms)? Are we investing in the differentiators? Is the organisation actually ready for strategic design?

And once the boundaries exist, Architecture Fitness Functions keep each small step inside them.

From chapter 3 of Domain-Driven Platform Engineering.