Before we start — the one thing to hold onto
Most teams think they have a naming problem. Services called UserManager, DataProcessor, BusinessLogic. They rename things, argue about it in code review, and nothing improves. The names aren't the problem.
A domain isn't a table in your database or a folder in your codebase. It's a boundary around a coherent set of business concepts — with its own language, its own rules, and its own reason to change.
That one idea changes everything. It turns architecture arguments about naming into conversations about ownership, autonomy, and business intent.
Keep it in mind.
Purpose
The goal of this workshop is concrete: redesign how your teams think about system boundaries — by drawing them around business domains, not technical layers.
I've worked with teams whose "User" service owned thirty-two unrelated concepts because everything touched a user. Billing touched users. Notifications touched users. Access control touched users. The service grew until nobody understood it, and every change broke something unrelated. That's not a code problem. It's a domain boundary problem.
You'll leave with a domain map your whole organisation can read, a bounded context canvas for each core domain, and a ubiquitous language your developers and business stakeholders actually share.
Who Should Attend
This workshop is designed for the people who decide where boundaries go — and live with the consequences when they're wrong.
- Enterprise & Solution Architects
- Principal Engineers, Tech Leads
- Senior Developers involved in system design
- Product Managers who work closely with engineering
Typical team size: 6-10 participants
Format: In-person strongly preferred (virtual available with facilitated tooling)
Try it yourself — The boundary audit
Pick any service in your system. List everything it's responsible for. Now ask: do all of these things change for the same reason? Do all of these things belong to the same business team?
If the answer to either question is no — that's a domain boundary problem, and this workshop is for you.
What You'll Achieve
By the end of this workshop, you will have:
- A domain map of your core, supporting, and generic subdomains
- Bounded context canvases capturing ownership, language, and rules per domain
- A ubiquitous language glossary — same words, same meaning, everywhere
- A context map showing how your domains integrate and where seams exist
- Identification of your most costly domain boundary violations
- A prioritised refactoring or migration conversation to fix them
These aren't diagrams you'll store in Confluence and forget. They're the foundation of every architecture decision your teams make next quarter.
Typical Outcomes
Immediate outcomes (within 1 week):
- Shared domain map visible to technical and business stakeholders
- Ubiquitous language glossary adopted by at least one team
- Identified top 3 boundary violations causing the most friction
Short-term outcomes (within 1 month):
- Bounded context ownership assigned to teams
- New features being designed domain-first, not database-first
- Reduced cross-team dependency surprises
Long-term outcomes (3-6 months):
- Cleaner service boundaries with fewer unintended couplings
- Faster onboarding — new engineers understand the system through domains, not diagrams
- Architecture conversations anchored in business language, not technical jargon
Workshop Structure
Day 1:
- Morning (3 hours): Domain discovery — mapping your business, not your codebase
- Afternoon (3 hours): Bounded context design — drawing boundaries with intention
Day 2:
- Morning (3 hours): Ubiquitous language — building a glossary that sticks
- Afternoon (3 hours): Context mapping — how your domains talk to each other
Total duration: 2 days (can be condensed to 1 day focused on domain mapping and bounded contexts)
Adjustable: Yes — can tailor based on system complexity and team maturity
Try it yourself — The language test
Pick any concept your team talks about daily. Ask five people — two developers, one product manager, one business stakeholder, one QA engineer — to define it. Write down each definition.
If you get five different answers, you don't have a shared language. This workshop builds one.
Prerequisites & Preparation
Before the workshop:
- Participants identify 3-5 services or system areas causing the most friction
- Bring existing architecture diagrams, service maps, or team topology documents
- Note where the same word means different things to different teams
Recommended team composition:
- 2-3 Enterprise or Solution Architects
- 2-3 Principal Engineers or Tech Leads
- 1-2 Senior Developers per domain being discussed
- 1-2 Product Managers (essential — they carry the business language)
How to know if this landed
You'll know this has landed when someone stops asking "which service should own this?" and starts asking "which domain does this belong to?" They can draw the boundary of a bounded context on a whiteboard and explain why it stops where it does. They catch domain language violations in pull requests. They design new features by identifying the domain first.
What changes when the mental model clicks
I've run this session with teams who had no idea why their microservices were still tightly coupled after three years of trying to decouple them. The architecture looked clean. The deployments were independent. But every feature change still touched five services — because the domains were wrong, even if the services were separate.
What changes after this workshop:
Teams stop designing systems around what they know how to build and start designing around what the business actually does. The domain discovery exercise tends to be the moment things click — people realise their biggest services aren't big because of complexity, they're big because they never drew a boundary.
The ubiquitous language work tends to immediately change how teams write tickets, name variables, and talk to product. The conversations get shorter. The misunderstandings get fewer. They stop blaming "unclear requirements" when the real problem was that engineering and business were using the same words to mean completely different things.
Book a Workshop
Ready to give your architecture team the domain clarity they've been missing?
or
1-2 day facilitated workshop includes domain discovery, bounded context design, ubiquitous language glossary creation, context mapping, and a prioritised refactoring conversation.