아키텍처
도메인 주도 개발 전환 이야기
두줄요약
도메인 문서화와 계층형 패키지 구조로 Flask 백엔드의 중복 로직과 불명확한 경계를 개선했습니다.\nResolver 로직을 Service·Repository·Entity로 재배치하며 도메인 중심 리팩터링 방향을 정리했습니다.
문제 상황
- Entity·GraphQL Resolver 중심 구현으로 도메인 명세 부재, 중복 로직, API별 상이한 동작 가능성
- 앱·백오피스 스쿼드의 동일 도메인 병행 개발에 따른 기능·코드 충돌 우려
- 기능 성장에 비례한 구조 복잡도와 생산성 저하 가능성
해결 방법
- 주요 도메인과 하위 도메인, 도메인별 행위·속성을 문서화하고 행위를 명령·조회로 구분
- 스프린트 버퍼 시간을 활용한 점진적 문서화·구조 개편 로드맵 수립
- Resolver의 비즈니스 로직을 도메인 Service·Repository로 이동하고 Entity 행위 강화
구조와 흐름
- 애플리케이션·도메인·인프라 3계층으로 단순화한 Layered Architecture
- 애플리케이션의 도메인 기능 접근을 Component로 제한해 경계와 일관성 확보
- 도메인의 애플리케이션 의존 금지와 SQLAlchemy 의존 예외, 코드 리뷰 기반 의존성 정책 관리
트레이드오프
- 도메인 모델과 영속성 모델 분리 대신 SQLAlchemy 의존 허용으로 lazy loading과 구조 단순성 선택
- Flask 환경의 IoC Container 부재와 DI 라이브러리 도입 비용을 고려한 Service·Repository 생명주기 관리 필요
