아키텍처
AI 코딩 시대, DDD가 더 필요해진 이유
두줄요약
Go 신용 서비스의 핸들러 중심 구조를 DDD-lite와 Clean Architecture로 정비한 과정을 공유했습니다. 명확한 도메인 경계가 AI 코딩의 탐색·리뷰 효율도 높인다고 설명합니다.
문제 상황
- Go 마이크로서비스 성장에 따른 핸들러 중심 로직 집중과 기술·벤더 단위 폴더 분산
- 중복 코드, 얽힌 의존성, 변경 영향 범위 파악과 도메인 규칙 테스트의 어려움
구조와 흐름
- 신용점수·신용변동 등 비즈니스 개념별 바운디드 컨텍스트 구성
- 컨텍스트별 handler·application·domain·infrastructure 4계층 적용
- domain의 포트와 infrastructure의 어댑터 분리를 통한 단방향 의존성 유지
해결 방법
- aggregate·이벤트 소싱 대신 DDD-lite와 Clean Architecture의 핵심 원칙 선택
- KCB 중심 supporting 폴더를 해체하고 신용점수 컨텍스트의 infrastructure 어댑터로 이동
- 핸들러의 약관·신용 규칙·리포지토리 오류 해석을 application 서비스와 각 도메인으로 이관
성능/운영 포인트
- 기능 변경을 컨텍스트 폴더에 국한해 PR 리뷰 범위와 피로도 축소
- 명확한 코드 위치와 계층 컨벤션으로 AI 코딩 에이전트의 탐색 범위 및 토큰 사용량 감소
- AGENTS.md와 /ddd-refactor 스킬을 통한 에이전트 준수 규칙 표준화 시도
