아니요, MongoDB는 설계를 건너뛴다는 의미가 아닙니다.

Source: Dev.to

도메인‑주도 설계와 MongoDB

MongoDB와 함께라면 도메인‑주도 설계(DDD)가 개발자에게 비즈니스 로직 및 접근 패턴에 데이터 모델을 맞춤으로써 견고한 시스템을 구축할 수 있게 해줍니다.

개발자는 종종 문서 데이터베이스가 SQL 데이터베이스처럼 엄격한 구조를 갖추지 못한다는 이유로 데이터 무결성을 소홀히 한다는 부당한 비난을 받습니다. 이러한 오해 때문에 일부 DBA는 관계형 데이터베이스만이 데이터 품질을 보장할 수 있다고 믿으며, MongoDB를 사용하면 데이터 모델링을 잘못하게 된다고 생각합니다.

실제로 개발자도 DBA와 마찬가지로 데이터 무결성에 큰 관심을 가집니다. 애플리케이션의 도메인 모델에 상당한 노력을 투자하고, 실제 사용 사례를 반영하지 못하는 정규화된 구조에 매핑함으로써 모델이 약화되는 것을 피합니다.

문서 데이터베이스에서도 여전히 데이터 모델을 설계합니다. 차이점은 어디서 그리고 어떻게 설계가 이루어지는가에 있습니다—도메인 모델과 애플리케이션의 접근 패턴 바로 옆에서 말이죠. 이는 특히 DDD를 실천하는 팀에 해당하는데, 개발자는 도메인 객체, 관계, 사용 패턴을 이해하는 데 시간을 투자합니다.

데이터 모델은 개발 프로세스와 함께 진화합니다: 아이디어 회의, 프로토타이핑, 초기 피드백을 위한 최소 기능 제품(MVP) 출시, 그리고 안정적인 프로덕션‑준비 애플리케이션으로의 반복 개선.

관계형 vs 문서 모델링

관계형 모델링은 종종 애플리케이션에 대한 이해가 완전해지기 전에 정규화된 설계부터 시작합니다. 이후 이 모델은 다양한 미래 워크로드와 예측할 수 없는 데이터 분포를 모두 지원해야 합니다. 예를 들어, 학술 소프트웨어용 스키마가 초등학교와 대형 대학 모두에서 사용될 수 있습니다. 이는 관계형 데이터베이스의 강점—워크로드가 크게 달라져도 애플리케이션에 노출되는 논리 모델은 동일하게 유지된다는 점—을 보여줍니다.

문서 모델링은 특정 애플리케이션 사용에 맞춰 최적화됩니다. 도메인 모델을 정규화된 테이블로 변환해 추상화를 추가하고 성능 최적화를 숨기는 대신, MongoDB는 집계(aggregate)를 코드와 비즈니스 로직에 나타나는 그대로 저장합니다. 문서는 비즈니스 트랜잭션을 반영하며 디스크에 연속적인 블록으로 저장돼 물리적 모델이 도메인 스키마와 일치하고 접근 패턴에 최적화됩니다.

주요 비교

• 관계

  • 관계형 데이터베이스에서 “관계(relations)”는 튜플 집합이라는 수학적 개념을 의미하며, 엔터티 간 연결을 뜻하지는 않습니다. 정규화는 실제로 관계를 느슨하게 만들어, 엔터티를 나중에 쿼리 시점에 조인하도록 합니다.
  • 엔터티‑관계 다이어그램(ERD)은 기본키와 외래키를 통한 일대일 혹은 일대다 연결을 보여주지만, 탐색 방향이나 소유권을 포착하지 못합니다. 다대다 관계는 조인 테이블을 통해 두 개의 일대다 관계로 분해됩니다.

• UML vs ERD

  • UML 클래스 다이어그램은 탐색 방향, 연관, 집합(aggregation), 합성(composition), 상속 등 풍부한 의미를 제공합니다.
  • MongoDB에서는 이러한 개념이 자연스럽게 매핑됩니다:
    • 합성(예: 주문과 주문 라인)은 종종 임베디드 문서 형태로 나타나며, 동일한 수명 주기를 공유하고 부분 삭제를 방지합니다.
    • 집합(예: 고객과 그 주문)은 수명 주기가 다르거나 소유권이 공유될 때 레퍼런스로 구현됩니다.
    • 상속은 다형성을 통해 표현될 수 있어, ERD에서 흔히 요구되는 nullable 컬럼 우회 방식을 피할 수 있습니다.

• 스키마 강직성

  • 관계형 스키마는 엔터티에 대해 강직하지만, 관계는 런타임에 조인으로 해결됩니다. 이는 데이터 과학자가 분석 중에 상관관계를 발견하는 과정과 유사합니다.
  • MongoDB의 스키마‑유연한 접근 방식은 도메인 모델과 저장 표현을 밀접하게 맞춥니다.

MongoDB의 스키마 유연성

MongoDB는 스키마‑유연하며, 스키마‑없지는 않습니다. 이는 초기 단계 프로젝트—아이디어 회의, 프로토타이핑, MVP 구축—에 특히 유용합니다. 데이터를 쓰기 전에 데이터 정의 언어(DDL) 문장을 실행할 필요가 없기 때문입니다. 스키마는 애플리케이션 코드에 존재하고, 문서는 그대로 저장되며 초기 검증이 없습니다.

모델이 성숙해지면 스키마 검증 규칙을 데이터베이스에 직접 정의할 수 있습니다(필수 필드, 데이터 타입, 허용 범위 등). 모든 필드를 한 번에 선언할 필요는 없으며, 검증은 점진적으로 추가해 여러 컴포넌트가 동일 필드에 의존하거나 인덱싱이 필요할 때 일관된 구조를 보장합니다.

스키마 유연성의 장점

• 빠른 프로토타이핑: 즉시 검증을 신경 쓰지 않고 자유롭게 필드를 추가할 수 있습니다.
• 통제된 진화: 이후 검증을 활성화해 데이터베이스가 무결성을 강제하도록 하면, 애플리케이션 측에서 반복적인 체크를 줄일 수 있습니다.
• 물리적 경계 강제: 예를 들어, 주문 항목 배열이 일정 크기를 초과하지 않도록 검증할 수 있습니다. MongoDB는 실패 대신 경고를 로그에 남겨 애플리케이션 가용성을 유지하면서 잠재적 이상을 표시하도록 할 수 있습니다.

참조 무결성 및 관계

SQL 데이터베이스에서는 외래키가 제약 조건으로 작동해 이상 현상(고아 행, 연쇄 삭제)을 방지하지만, JOIN 절에서 사용되는 것은 아닙니다; 관계는 쿼리 시점에 정의됩니다.

MongoDB는 다른 접근 방식을 취합니다:

• 임베딩은 밀접하게 결합된 엔터티(예: 주문 라인을 주문 문서 내부에 포함)를 설계 단계에서 고아 항목이 발생하지 않도록 합니다.
• 레퍼런스는 애플리케이션 로직에 의해 처리되며, 보통 안정적인 컬렉션에서 값을 읽어 임베딩하기 전에 사용됩니다.

MongoDB 모델은 알려진 접근 패턴과 수명 주기에 맞춰 설계되므로, 참조 무결성은 일반적인 제약이 아니라 비즈니스 규칙을 통해 유지됩니다. 이는 가격 인하가 진행 중인 주문에 적용될 수 있지만, 가격 인상이 적용되지 않을 수 있는 등 실제 비즈니스 프로세스와 유사합니다.