데이터베이스 중심 개발에서 진짜 DDD로 선회하기 1편

공통 코드와 여분 필드, 촘촘한 FK로 모든 문제를 해결하려던 데이터베이스 중심 설계에서 도메인 중심 개발로 관점을 바꾼 팀의 경험이다. DDD를 어려운 설계 교리로 보던 오해를 이벤트 스토밍, 몹 프로그래밍, 테스트 기반 실험으로 풀었다. 도메인 모델을 먼저 만들고 MongoDB·MySQL·AWS 인프라를 목적에 맞춰 선택하면서 개발뿐 아니라 배포·운영까지 DDD의 범위임을 체감한다.

핵심 포인트

데이터를 넣으면 끝이라는 결과 중심 사고는 시스템의 성장 가능성과 후임 개발자의 선택지를 제한했다.
DDD는 특정 설계 기법이 아니라 도메인 문제를 탐험하고 개발·배포·운영 수단을 목적에 맞게 고르는 과정으로 해석했다.
이벤트 스토밍으로 비즈니스 사건과 사람들의 언어를 맞추고, 몹 프로그래밍으로 코드의 이름과 경계를 계속 검증했다.
테스트를 가설 검증 장치로 사용해 기술 스택 확정을 미루고 도메인 계층을 먼저 발전시켰다.
MongoDB와 MySQL 혼용, 드라이버·라이브러리 버전, 처리량·인스턴스 크기·모니터링까지 도메인 요구에 맞추는 후반 작업이 더 어려웠다.

상세 정리

과거 설계: 솔루션처럼 어디서나 쓸 수 있도록 공통 코드, 미래용 필드, 다수 FK로 테이블을 강하게 연결했다.
문제 자각: 데이터가 저장되는 결과를 목표로 삼아 실제 사용자의 문제 해결 과정과 시스템 변화 가능성을 놓쳤다. 닫힌 스키마가 선택지를 빼앗았다.
첫 오해: DDD 없이도 개발할 수 있으므로 이상주의나 신앙에 가깝다고 생각했고, 주변 실패 사례를 근거로 현실성이 낮다고 봤다.
두 번째 오해: Design이라는 이름 때문에 코드를 짜기 전 설계 단계의 기법으로만 여겼다.
세 번째 오해: 유비쿼터스 랭귀지, 바운디드 컨텍스트, 전략적 디자인 같은 용어가 서로 이어져 진입 장벽이 높았다.
재정의: 팀 경험을 통해 DDD를 도메인 문제를 철저히 탐험하고 모든 적절한 수단을 동원하는 접근으로 바꿔 이해했다. Development·Deployment·운영 방향도 포함했다.
학습 과정: 에릭 에반스와 반 버논의 책을 반복해 읽었지만 구현 감각은 책만으로 생기지 않았다.
이벤트 스토밍: 기존 시스템을 그대로 정답으로 받아들이지 않고 사건과 비즈니스 타당성을 포스트잇으로 논의했다. 장기 수정에는 Miro도 활용했다.
컨텍스트 통합: 가상의 부서와 사람이 어떤 메시지를 주고받는지 그리며 팀의 도메인 지식을 맞췄다.
몹 프로그래밍: 클래스·인터페이스·메서드 이름을 정할 때마다 현장 사용자의 언어인지, 해당 바운디드 컨텍스트의 관심사인지 질문했다.
반복 실험: 답을 한 번에 확정하지 않고 그림·코드·토론으로 가설을 세운 뒤 테스트를 작성하고 통과시키며 리팩토링했다.
테스트 역할: 이름과 모델을 여러 번 바꾸더라도 동작을 보존하고 어느 가설이 더 타당한지 판단할 기반이 됐다.
기술 선택 지연: 도메인 테스트 커버리지를 100%에 가깝게 유지하면서 필요한 인프라를 하나씩 붙였다. 익숙한 환경에 서비스를 끼워 맞추지 않았다.
운영 난관: 개발 단계가 끝나자 설정, 성능, 배포, 모니터링 문제가 나타났다. DDD 원리만 이해해서는 운영 가능한 시스템을 만들 수 없었다.
인프라 적응과 협업 결과: 도메인 특성에 따라 MongoDB와 MySQL을 함께 쓰고 드라이버·라이브러리 버전 문제를 해결했다. AWS 담당 조직과 처리량·인스턴스 크기를 실험해 과거 레거시보다 높은 성능으로 전례 없는 트래픽을 버틴 환경을 찾았다.