From DDD to Database Design: Transforming Relational and NoSQL Schemas

1. Persistence of Domain Objects

In modern software architecture, data is treated as domain objects that exist throughout the system lifecycle. Creating, updating, or deleting a record corresponds to creating, modifying, or destroying a domain object. Because servers are not infinitely powerful, objects that are not needed immediately must be persisted to disk, and databases become one implementation of that persistence.

2. Designing Domain Models

Domain‑model design sits at the core of the analysis process. First, a use‑case model identifies required functionalities; then a domain model captures business entities as classes. Each class expresses both data structure (attributes) and behavior (methods), allowing a single design step to cover both database schema and program logic.

3. Traditional Four Relationships

The domain model’s classes map directly to database tables. The four classic relationships—one‑to‑one, many‑to‑one, one‑to‑many, and many‑to‑many—are converted as follows:

One‑to‑One : Implemented with a foreign key that also serves as the primary key in the dependent table. Example: a "Fault Behavior" must have exactly one "Appeal Detail".

Many‑to‑One : The many side holds a foreign key referencing the one side. Example: each fault behavior references a tax officer, a taxpayer, and a fault type.

One‑to‑Many : The many side contains a foreign key to the one side, forming a parent‑child relationship such as an "Appeal Form" and its multiple "Appeal Details".

Many‑to‑Many : Introduced via a junction table that stores pairs of primary keys, e.g., "User Role" and "Permission".

4. Inheritance Relationship Design (Three Schemes)

Inheritance exists in the domain model but not directly in relational tables. Three common mapping strategies are:

Single Table with Discriminator : All subclasses share one table; a discriminator column indicates the subclass. Simple but can cause many nullable columns (table sparsity).

Class‑Table Inheritance : Each subclass gets its own table containing subclass‑specific columns plus the primary key inherited from the parent table. Suitable when queries target a single subclass, but cross‑subclass queries require joins across multiple tables.

Concrete Table Inheritance : The parent table stores only common fields; each subclass table stores both common and specific fields. Queries for all subclasses can be satisfied by reading the parent table, then fetching subclass details as needed.

5. NoSQL Database Design

NoSQL databases abandon the third‑normal‑form discipline and aim to eliminate joins. Data is stored in wide tables or document structures, tolerating many nullable fields because storage is sparse. Example of a VAT invoice stored as a single MongoDB document:

{
  _id: ObjectId("7df78ad8902c"),
  fpdm: "3700134140",
  fphm: "02309723",
  kprq: "2016-01-25 09:22:45",
  je: 70451.28,
  se: 11976.72,
  gfnsr: { nsrsbh: "370112582247803", nsrmc: "联通华盛通信有限公司济南分公司" },
  xfnsr: { nsrsbh: "370112575587500", nsrmc: "联通华盛通信有限公司济南分公司" },
  spmx: [
    { qdbz: "00", wp_mc: "蓝牙耳机 车语者S1 蓝牙耳机", sl: 2, dj: 68.37 },
    { qdbz: "00", wp_mc: "车载充电器 新在线", sl: 1, dj: 11.11 },
    { qdbz: "00", wp_mc: "保护壳 非尼膜属 iPhone6 电镀壳", sl: 1, dj: 24 }
  ]
}

In this document, one‑to‑one and many‑to‑one relationships are represented as embedded objects (e.g., gfnsr, xfnsr), while one‑to‑many and many‑to‑many relationships become arrays of objects (e.g., spmx).

Inheritance can also be stored flexibly: a single collection holds records of different sub‑types, each with its own set of fields, as shown below:

{ _id: ObjectId("79878ad8902c"), name: "Jack", type: "parent", partner: "Elizabeth", children: [{ name: "Tom", gender: "male" }, { name: "Mary", gender: "female" }] }
{ _id: ObjectId("79878ad8903d"), name: "Bob", type: "kid", mother: "Anna", father: "David" }

6. Summary

Applying DDD moves database design from a pure data‑structure exercise to a domain‑model‑driven activity. The four classic relational relationships map directly to tables, inheritance requires careful scheme selection, and NoSQL demands a fundamentally different approach that embraces wide documents and embedded structures. Choosing the right strategy based on business scenarios reduces future migration costs and aligns the data layer with evolving architectural needs.