Domain Specification

Define What the Domain Means

Before software can execute a business, the business itself needs to be understood.

A domain specification captures that understanding in a precise and structured form.

It describes the concepts that exist, the relationships between them, the rules that govern them and the behavior that makes the domain operate.

From Knowledge to Structure

Business knowledge is rarely born as a formal system.

It exists in regulations, contracts, processes, spreadsheets, policies, conversations, documentation and the experience of people working inside the domain.

The first challenge is transforming that knowledge into a coherent model.

A domain specification provides that model.

What Does the Domain Contain?

Depending on the domain, a specification may define:

Entities — what exists.

Relationships — how things are connected.

Rules — what must or must not happen.

Policies — what governs decisions and access.

States — the conditions an entity can be in.

Transitions — how entities move between states.

Operations — what can be done.

Events — what happens within the domain.

Together they describe not just the structure of the business, but its behavior.

The Domain Before the Implementation

The specification exists independently from the technology used to implement it.

That means the domain can be understood without first understanding the code.

It can also be transformed into different implementations without redefining the business every time.

This is what makes the domain durable.

Define what the business means before defining how technology implements it.