Domain Model vs Data Model: When to Use Each and Avoid Common Pitfalls

1 Domain Model and Data Model Definitions

Domain models focus on business knowledge, representing core entities and their relationships to make business semantics explicit; extensibility is secondary. Data models focus on data storage, emphasizing scalability and performance rather than rich business semantics.

Both models use entities and relationships, which is why they are easily mixed up, especially when using ER diagrams for data modeling.

2 Mistaking the Domain Model for a Data Model

In a pricing‑optimization project, the domain model defines configuration data such as price rules and ranges. Designing the storage based on this model leads to two tables (price_rule and price_range), which is an unnecessary duplication.

A better approach stores all range information in a single JSON field within the price_rule table, reducing table count and maintenance cost.

Maintaining one table is cheaper than two.

JSON storage makes extending the data (e.g., adding a suggested‑price range) easier without schema changes.

However, business code must convert JSON data into domain objects to retain clear business semantics while benefiting from the data model’s flexibility.

3 Mistaking the Data Model for a Domain Model

Data models should be highly extensible; Alibaba’s business‑centered middle platform demonstrates this with vertical tables like auction_extend that support countless scenarios.

But treating these extensible structures as domain objects leads to code that manipulates features rather than true domain entities, violating object‑oriented principles.

4 Letting Each Model Do Its Job

Separate domain and data models: the domain model expresses business semantics explicitly, while the data model ensures storage extensibility and performance.

Using the COLA architecture, a gateway can translate between Data Objects (DO/DTO) and domain entities, providing decoupling and improving maintainability.

5 Further Thoughts on Extension

For simple configuration data, a JSON field suffices; for complex, high‑volume data, vertical tables or other extensible designs are appropriate.

Salesforce’s metadata‑driven approach shows an extreme case of data‑centric extensibility, but it still requires mapping metadata to domain concepts for maintainable code.

Related links: [1] https://github.com/alibaba/COLA [2] https://developer.salesforce.com/wiki/multi_tenant_architecture