SQL.What are domain types (or constraints on data types), and how do they help enforce data correctness?

his is a schema design / data integrity question. Interviewers ask it to see whether you push correctness into the database, not only into application code.

Short, interview-ready answer

Domain types and constraints restrict what values a column can hold, encoding business rules directly in the schema so invalid data cannot be stored, regardless of the application.

1️⃣ What are “domain types” (conceptually)

A domain is a restricted version of a base data type.

Think of it as:

“Not just an INT — an INT with meaning and rules.”

Instead of repeating rules everywhere, you define them once and reuse them.

2️⃣ Constraints vs domain types

Constraints on a column

Rules applied per column:

amount DECIMAL(10,2) NOT NULL CHECK (amount >= 0)

1 2	amount DECIMAL(10,2) NOT NULL CHECK (amount >= 0)

Domain type (PostgreSQL example)

Rules applied to a reusable type:

CREATE DOMAIN positive_amount AS DECIMAL(10,2)
  CHECK (VALUE >= 0);

CREATE DOMAIN positive_amount AS DECIMAL(10,2)

CHECK (VALUE >= 0);

Then used like:

amount positive_amount NOT NULL

1	amount positive_amount NOT NULL

Same rule, centralized.

3️⃣ Common constraint types (must know)

NOT NULL

email TEXT NOT NULL

1 2	email TEXT NOT NULL

Prevents missing mandatory data.

CHECK

CHECK (age >= 18)

1 2	CHECK (age >= 18)

Encodes business rules.

UNIQUE

UNIQUE (email)

1 2	UNIQUE (email)

Prevents duplicates.

FOREIGN KEY

FOREIGN KEY (user_id) REFERENCES users(id)

1 2	FOREIGN KEY (user_id) REFERENCES users(id)

Enforces referential integrity.

ENUM / domain-like restrictions

CHECK (status IN ('NEW', 'PAID', 'CANCELLED'))

1 2	CHECK (status IN ('NEW', 'PAID', 'CANCELLED'))

4️⃣ Why domain types are powerful (senior insight)

❌ Without domains

Rules are duplicated:

in services
in validations
in migrations
inconsistently enforced

Eventually:

one path forgets validation
bad data leaks in
bugs appear years later

✅ With domains / constraints

Invalid data cannot be stored
All writers are protected:
- app
- scripts
- migrations
- admin tools

The database becomes the last line of defense.

5️⃣ Real-world examples (very interview-friendly)

Example 1: Email

email TEXT CHECK (position('@' in email) > 1)

1 2	email TEXT CHECK (position('@' in email) > 1)

(Not perfect, but enforces basic sanity.)

Example 2: Money

CREATE DOMAIN money_amount AS BIGINT
  CHECK (VALUE >= 0);

CREATE DOMAIN money_amount AS BIGINT

CHECK (VALUE >= 0);

Stores cents, guarantees non-negative.

Example 3: Status

CREATE DOMAIN order_status AS TEXT
  CHECK (VALUE IN ('NEW', 'PAID', 'CANCELLED'));

CREATE DOMAIN order_status AS TEXT

CHECK (VALUE IN ('NEW', 'PAID', 'CANCELLED'));

No accidental "new" or "PAYED".

6️⃣ Why this matters for backend engineers

🔴 Application-only validation is not enough

Multiple services
Background jobs
Manual fixes
Future code changes

Sooner or later:

Something bypasses validation.

✅ Constraints give you:

Data correctness by construction
Simpler application code
Safer refactoring
Easier debugging

7️⃣ Trade-offs (be honest in interviews)

⚠️ Constraints can:

Break bad legacy data
Require careful migrations
Slow writes slightly (negligible vs correctness)

Senior answer:

Correctness > convenience.

8️⃣ Interview-ready final answer (clean)

“Domain types and constraints restrict allowed values for columns, encoding business rules directly into the database schema.
They prevent invalid data from being stored regardless of how the database is accessed, improving correctness, consistency, and long-term maintainability.
They move validation from application code into the data model itself.”

🚩 Red flags interviewers notice

If a candidate says:

“We validate everything in code”
“Constraints slow the database”
“Foreign keys are optional”

👉 That’s not senior-level thinking.