📄️ React로 이해하는 도메인 주도 개발
이 문서는 Google Ads 캠페인 설정을 하나의 연속 예제로 사용해 DDD의 핵심 개념과 React 적용 방법을 학습하기 위한 안내서다.
📄️ React로 이해하는 도메인 주도 개발
Google Ads 캠페인 설정을 예제로 DDD의 출발점과 프런트엔드의 경계 질문을 정리한다. DDD의 목적은 클래스를 늘리는 것이 아니라, 중요한 업무 판단이 UI와 API 코드에 흩어져 서로 달라지는 문제를 막는 데 있다.
📄️ DDD가 필요한 이유
DDD(Domain-Driven Design)는 모든 화면에 적용하는 코드 구성 기법이 아니다. 비즈니스 규칙이 자주 바뀌고 같은 데이터도 업무 맥락에 따라 다르게 해석될 때, 소프트웨어의 중심을 화면이나 API가 아니라 도메인 지식에 두는 설계 방식이다.
📄️ Ubiquitous Language와 Bounded Context로 비즈니스 경계 나누기
DDD의 모델은 개발자가 혼자 만드는 클래스 구조가 아니다. 기획자, 광고 운영자, 디자이너, 개발자가 같은 업무를 같은 말로 설명하고 그 말이 유효한 범위를 코드 경계로 만드는 과정이다.
📄️ 도메인 모델 만들기
도메인 모델은 API 응답 형태를 그대로 옮긴 데이터 객체가 아니라, 업무 용어와 변경 규칙을 실행 가능한 코드로 표현한 모델이다. 이 문서에서는 Google Ads 캠페인을 다음 흐름으로 모델링한다.
📄️ React와 도메인 연결하기
앞 장에서 만든 Campaign, CampaignBudget, 게시 상태 전이 규칙을 React에 연결한다. 핵심은 React를 도메인의 주인이 아니라 사용자의 입력을 전달하고 결과를 보여 주는 입력 Adapter로 두는 것이다.
📄️ Google Ads 캠페인 설정 실전 적용과 검증
앞 장의 Hexagonal Architecture에 Google Ads 캠페인 설정 흐름을 연결한다. 예제의 브라우저는 자체 Backend for Frontend만 호출하고, OAuth credential과 developer token이 필요한 Google Ads Adapter는 서버에서 실행된다고 가정한다.
📄️ React DDD로 Google Ads 캠페인 예산 추천 설계하기
캠페인 수정 화면에서 여러 예산 추천을 계산하고, 우선순위와 묶음 규칙을 적용하며, 추천 선택 시 API Mutation과 웹 로깅을 실행하는 흐름을 함수형 Domain과 Hexagonal Architecture로 설계한다. A/B 실험으로 추천 타입이 5개에서 6개로 늘어나더라도 React와 Domain의 책임은 유지한다.