DDD 그거 그렇게 하는 거 아닌데 #우아콘2024 #우아한형제들

문제를 합의하기 전에 DDD·TDD·hexagonal architecture 같은 낯선 이름부터 꺼내면 team의 방어 반응만 키우므로, 먼저 현재 고통과 해결 이유를 논의하고 실행 수단은 뒤에 선택해야 한다. Domain 경계도 모른 채 microservice와 package를 먼저 나누면 기술 복잡성과 결합만 늘고 완벽한 설계는 변화하는 요구에서 존재할 수 없으므로, monolith와 단일 package에서 시작해 학습에 따라 분리하는 접근을 권한다.

Domain 지식이 없는 greenfield에서는 getter·setter가 있는 빈약한 model이라도 먼저 동작하게 만들고, 반복되는 상태 변경을 객체에게 보내는 message와 의미 있는 method·value로 옮기며 점진적으로 풍부한 model을 발견한다. 개발자만 이해하는 class 이름이 아니라 현업과 함께 용어의 정의·동의어·금지어를 기록하는 ubiquitous language를 만들고, 같은 ‘과제’가 출제물과 제출물을 가리키는 혼선을 실제 model 이름에 반영한다.

어제까지 작성한 code도 오늘의 legacy인 brownfield에서는 개발자가 software가 해결하는 business domain과 사용자의 활동을 이해해야 과도하거나 부족하지 않은 확장 지점을 정할 수 있다. 큰 domain을 상품·전시·주문·결제·정산 같은 subdomain으로 나누고 core·supporting·generic으로 분류해 제한된 사람과 시간을 차별화 영역에 집중하며, event storming·domain storytelling으로 이해를 모든 참여자와 계속 검증한다.

같은 용어가 다른 의미를 갖거나 같은 대상을 다르게 부르는 지점을 기준으로 team마다 생각하는 bounded context를 그려 비교하고, 영향이 작거나 중요한 경계부터 하나씩 떼어내며 조직 간 협업 방식까지 전략적 설계로 다룬다. DTO·dependency inversion·anti-corruption layer로 외부 model을 번역하다 보면 domain 중심 architecture가 자연스럽게 나타나며, 호기심과 동맹을 활용해 필요한 DDD idea만 도입해야 ‘DDD는 원래’라는 주장 없이도 project를 개선할 수 있다.