Cracking the enterprise domain

Enterprise onboarding is not signup with more fields.

A real B2B customer arrives with a legal structure, regional data rules, security requirements, contract constraints, billing promises, and internal operating units. If engineering reduces all of that to tenant_id: string, the model has already lost the business.

DDD starts before code. It starts by learning the domain well enough that the model can defend the business.

Enterprise onboarding starts with structure, not handlers

What this series is

This is not a catalog of DDD patterns. It is a walkthrough of one enterprise onboarding domain, from business language to implementation boundaries.

The series starts with the model because that is where most teams make the first mistake. Code comes later, after the business concepts are stable enough to deserve names.

The enterprise problem space

Marketing says account.

Sales says global contract.

Legal says contracting entity.

InfoSec says data isolation region.

Customer success says tenant.

Developers write tenant_id.

Those words are not synonyms. In a shared-schema SaaS system, confusing them can leak data across regions, apply the wrong contract terms, or provision a tenant into the wrong residency boundary.

The domain is not “create a tenant.” The domain is:

Safely onboard a global enterprise customer into one or more isolated operational tenants while honoring contract, residency, access, quota, and compliance constraints.

That sentence is the beginning of the model.

The case we will use

The customer in this series is Northstar Health Group, a fictional enterprise healthcare company.

Northstar signs one global contract, but it cannot run as one flat tenant:

• Northstar Global is the parent legal/commercial relationship.
• Northstar US operates under HIPAA and must keep protected health data in a US region.
• Northstar EU operates under GDPR and must keep EU personal data in an EU region.
• Each regional division needs one or more operational tenants for business units like claims, clinical operations, and partner support.
• The contract buys 100 seats for the first rollout, but Sales wants to reserve expansion capacity.
• InfoSec requires SAML federation before any tenant is marked production-ready.
• Platform must create the tenant’s shared-schema database records in the correct residency region and seed default roles before users can sign in.

That is the scenario every post will return to. If a pattern does not help onboard Northstar safely, it does not belong in the article.

The core language

For this series, the domain model starts with three structural concepts:

That vocabulary is not documentation garnish. It decides what the code can express.

At this point, do not start with TypeScript tricks. Start by checking whether the team can use these words consistently in product decisions, customer calls, incident reviews, support tickets, and code review.

Before: one id to rule them all

This is how enterprise SaaS products drift into danger:

async function createTenant(input: { accountId: string; tenantId: string; region: string }) {
  await db.tenant.create({
    data: {
      account_id: input.accountId,
      tenant_id: input.tenantId,
      region: input.region,
    },
  });
}

What is accountId? The Salesforce account? The billing account? The global organization? The regional legal entity?

What is region? The user’s preferred UI region? The data residency boundary? The deployment target?

The code accepts the wrong questions.

After: model the business structure

The first tactical move is not an aggregate. It is a clearer model of the business structure:

1. A Global Organization owns the commercial relationship.
2. A Regional Division belongs to that organization and carries residency obligations.
3. A Business Unit / Tenant belongs to a regional division and is where users work.
4. The tenant must satisfy a Residency Policy.
5. The tenant must fit inside a Contract entitlement.
6. The tenant must reach Identity readiness: SAML metadata accepted, required Entra ID groups mapped, and first admin access tested.

Now a code review can ask domain questions:

• Does this tenant belong to this regional division?
• Is the division allowed to use this residency policy?
• Does the contract cover this tenant’s quota request?
• Which legal entity owns the data?

Those are better questions than “did we pass the right string?”

The TypeScript representation matters, but it should follow the language. In later posts, the code examples use typed identities and value objects. They are useful only because the business concepts have already been separated.

Core domain versus supporting domains

Not every concept deserves the same modeling pressure.

In this series, enterprise onboarding is the core domain because mistakes here create customer-visible failures and compliance exposure. Billing, IAM, and security compliance are important supporting domains with their own models. Email delivery and template editing are generic capabilities.

That classification matters. DDD does not mean every module gets an aggregate. It means the core model gets protected where the business risk justifies the cost.

The takeaway

A shared vocabulary in code is the first line of defense against data isolation failures.

Before designing workflows, events, repositories, or aggregates, make sure the model can distinguish the business concepts that the enterprise actually cares about.

Principles to apply in your own work

1. Pick one enterprise customer currently in onboarding.
2. Write down every business noun used by Sales, Legal, InfoSec, Finance, Support, and Engineering.
3. Mark which nouns are synonyms and which are different concepts.
4. Write one plain-language definition for each concept.
5. Review one recent onboarding bug and identify which concept was blurred.

Avoid starting with folder names. If the business hierarchy is wrong, the folder structure will not save you.

Next: Strategic context mapping.