Applying DDD to Database Design in 4 Practical Steps

When a team starts a project, the usual habit is to draw an ER diagram and create tables before the domain model is clear, which leads to frequent schema changes as requirements evolve. DDD proposes the opposite: begin with a domain model where classes contain both attributes (data) and methods (behaviour), then treat the database as just one way to persist those objects.

Step 1 – Change mindset : Move from a "database‑centric" view to a "domain‑model‑centric" view. The database schema becomes a translation of the domain objects rather than the starting point.

Step 2 – Map the four relationship types that appear in a domain model to relational tables:

One‑to‑one: make the primary key of one side a foreign key on the other side and add a unique constraint to enforce the "at most one" semantics.

Many‑to‑one: add a foreign key on the "many" side; for queries, fetch the main table first and then fill in related data to avoid costly joins.

One‑to‑many: classic master‑detail structure; the child table holds a foreign key referencing the master, and the master object keeps a collection of children.

Many‑to‑many: introduce a junction table whose composite primary key consists of the two foreign keys.

When persisting, translate Chinese class and field names used for communication into English identifiers, choose appropriate column types, and decide nullability.

Step 3 – Handle inheritance with three alternatives, each suited to different query patterns:

Single‑table inheritance: store all subclasses in one table with a discriminator column. Simple but can lead to many nullable columns ("sparse" table) and wasted space.

Class‑table inheritance (shared primary key): each subclass gets its own table sharing the same primary‑key generator. Efficient when queries target a single subclass, but cross‑subclass queries require scanning all subclass tables.

Concrete‑table inheritance (parent‑child split): a parent table holds common fields; each subclass has its own table for specific fields. Queries for aggregates read only the parent table, while detailed views join the child tables. Most flexible for scenarios needing cross‑subclass queries.

The choice depends on the business’s query patterns; there is no universal silver bullet.

Step 4 – Adapt to NoSQL : Relational databases aim for third‑normal‑form to minimise redundancy, which often forces many joins that become performance bottlenecks under high concurrency. NoSQL favours wide tables or documents that denormalise data, eliminating joins. For example, an invoice that would require four tables and multiple joins in a relational DB can be stored as a single document with nested objects and arrays in a document store, and empty fields do not consume space, removing the "sparse table" issue.

Finally, the article provides a conversion checklist:

Map each domain class to a table; each attribute becomes a column.

Identify the relationship type and apply the corresponding mapping rule.

When inheritance appears, select one of the three strategies based on query patterns.

If targeting NoSQL, abandon strict normalisation and use wide tables or documents to avoid joins.

The core principle is that the domain model is the "Dao" (the way), while the database implementation is the "Technique" that can evolve with technology without changing business logic.