No, MongoDB Does Not Mean Skipping Design

Source: Dev.to

Domain‑Driven Design and MongoDB

With MongoDB, domain‑driven design (DDD) empowers developers to build robust systems by aligning the data model with business logic and access patterns.

Developers are often unfairly accused of neglecting data integrity because a document database lacks the rigid structure of an SQL database. This misconception leads some DBAs to believe that only relational databases can guarantee data quality, and that using MongoDB means data modeling will be done incorrectly.

In reality, developers care just as much about data integrity as DBAs. They invest significant effort in the application’s domain model and avoid weakening it by mapping it to a normalized structure that does not reflect actual use cases.

In a document database, you still design your data model; the difference is where and how the design happens—directly alongside the domain model and the application’s access patterns. This is especially true for teams practicing DDD, where developers spend time understanding domain objects, relationships, and usage patterns.

The data model evolves with the development process: brainstorming, prototyping, releasing a minimum viable product (MVP) for early feedback, and iterating toward a stable, production‑ready application.

Relational vs Document Modeling

Relational modeling often starts with a normalized design created before the application is fully understood. The model must then serve diverse future workloads and unpredictable data distributions. For example, a schema designed for academic software might be used by both primary schools and large universities. This illustrates the strength of relational databases: the logical model exposed to applications remains the same even when workloads differ greatly.

Document modeling is tailored to specific application usage. Instead of translating the domain model into normalized tables—adding abstraction and hiding performance optimizations—MongoDB stores aggregates directly as they appear in code and business logic. Documents reflect business transactions and are stored as contiguous blocks on disk, keeping the physical model aligned with the domain schema and optimized for access patterns.

Key Comparisons

• Relationships

  • In relational databases, “relations” refer to mathematical sets of tuples, not to the connections between them. Normalization actually loosens relationships, decoupling entities that are later joined at query time.
  • Entity‑relationship diagrams (ERDs) show simple one‑to‑one or one‑to‑many links via primary and foreign keys, but they do not capture navigation direction or ownership. Many‑to‑many relationships are modeled through join tables, which split them into two one‑to‑many relationships.

• UML vs ERD

  • UML class diagrams provide richer semantics: navigation direction, association, aggregation, composition, and inheritance.
  • In MongoDB these concepts map naturally:
    • Composition (e.g., an order and its order lines) often appears as embedded documents, sharing a life cycle and preventing partial deletion.
    • Aggregation (e.g., a customer and their orders) uses references when life cycles differ or ownership is shared.
    • Inheritance can be represented via polymorphism, avoiding the nullable‑column workarounds required in ERDs.

• Schema rigidity

  • Relational schemas are rigid for entities; relationships are resolved at runtime with joins, similar to a data scientist discovering correlations during analysis.
  • MongoDB’s schema‑flexible approach keeps the domain model and storage representation closely aligned.

Schema Flexibility in MongoDB

MongoDB is schema‑flexible, not schema‑less. This is valuable for early‑stage projects—brainstorming, prototyping, or building an MVP—because you don’t need to execute Data Definition Language (DDL) statements before writing data. The schema lives in application code, and documents are stored as‑is, without initial validation.

As the model matures, you can define schema validation rules directly in the database (field requirements, data types, accepted ranges). You don’t need to declare every field immediately; validation can be added incrementally, ensuring consistent structure when multiple components depend on the same fields or when indexing.

Benefits of schema flexibility

• Rapid prototyping: Add fields freely without worrying about immediate validation.
• Controlled evolution: Later, enable validation to let the database enforce data integrity, reducing the need for repetitive application‑side checks.
• Physical bounds enforcement: For example, you can validate that an embedded array of order items does not exceed a certain size. MongoDB can log a warning instead of failing outright, allowing the application to stay available while flagging potential anomalies.

Referential Integrity and Relationships

In SQL databases, foreign keys are constraints that help prevent anomalies (orphaned rows, cascading deletes) but are not used in the JOIN clause; relationships are defined at query time.

MongoDB takes a different approach:

• Embedding tightly coupled entities (e.g., order lines inside an order document) eliminates orphaned items by design.
• References are handled by application logic, often reading from stable collections before embedding values.

Because MongoDB models are built for known access patterns and life cycles, referential integrity is maintained through business rules rather than generic constraints. This mirrors real‑world processes where updates or deletions must follow specific conditions (e.g., a price drop may apply to ongoing orders, but a price increase may not).