아키텍처
AI 코딩 시대, DDD가 더 필요해진 이유
두줄요약
Go 서비스의 핸들러 중심 구조를 DDD-lite와 Clean Architecture로 리팩토링한 과정을 소개했습니다. 명확한 경계가 AI 코딩의 탐색·리뷰 범위도 줄인다고 설명합니다.
문제 상황
- Go 마이크로서비스 성장에 따른 핸들러 중심 로직 집중과 사실상 모놀리식화
- 기술·벤더 기준 폴더 분리로 인한 신용점수 기능 코드 탐색·변경 범위 파악 난항
- 핸들러의 인증, 약관, 조회, 변동 계산, 인프라 오류 처리 혼재와 규칙 복제
원인 분석
- 폴더 분리만 우선한 DDD 도입으로 KCB 데이터 출처 중심의 잘못된 바운디드 컨텍스트 형성
- 도메인·인프라·전송 계층 간 의존성 얽힘과 구현 세부 사항의 핸들러 노출
- 구성원 공통 기준과 PR 리뷰 범위 관리 부재
해결 방법
- 신용점수·신용변동·신용유저 등 비즈니스 개념 단위 바운디드 컨텍스트 구성
- handler·application·domain·infrastructure의 4계층과 domain 포트·infrastructure 어댑터 분리
- 435개 PR을 통한 전체 정비와 KCB 코드를 각 소유 컨텍스트의 어댑터로 이동
성능/운영 포인트
- 기능별 코드 응집에 따른 탐색 범위와 PR 리뷰 범위 축소
- 명확한 계층 컨벤션 기반 AI 코딩 에이전트의 읽기 코드량 감소와 결과물 일관성 향상
- AGENTS.md 규칙 및 /ddd-refactor 스킬을 통한 구조 준수 자동화 시도
