
## 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?

→ **[Book a Workshop](https://calendly.com/naveen-innoventurex/free-consultation-with-naveen)**

or

→ **[Contact me directly](/contact)**

*1-2 day facilitated workshop includes domain discovery, bounded context design, ubiquitous language glossary creation, context mapping, and a prioritised refactoring conversation.*

Stop designing systems around databases and frameworks. Start designing around your business domains — and watch your architecture conversations change overnight.

Domain-Driven Design & Strategic Design Workshop

Get your developers, domain experts, and business stakeholders in the same room, speaking the same language, discovering the same system — in one day.

Event Storming Workshop

Eliminate architectural ambiguity and technical decision bottlenecks through clear decision frameworks and accountability patterns.

Domain-Driven Design & Strategic Design Workshop

Related Workshops