[Architecture] DDD 알아보기 - 1
제이슨이 우아콘 2024에서 발표한 DDD 그렇게 하는거 아닌데를 글로 정리해봤습니다.
정리하고 보니 굳이 DDD에 국한된 이야기는 아닌 것 같았습니다. 어느 아키텍쳐, 어느 개발 방법론을 쓰든 필요한 내용이었습니다.
1. 구현보다 정의가 먼저: Greenfield 프로젝트의 자세
새로운 프로젝트(Greenfield)를 시작할 때 개발자가 가장 먼저 해야 할 일은 기술 스택 선정이나 DB 스키마 설계가 아니다.
- 문제의 본질 파악: 우리가 해결하려는 문제가 무엇인가? 왜 이 문제를 해결해야 하는가?
- Case by Case: 모든 상황에 들어맞는 정답은 없다. 문제가 정의된 후에야 비로소 그에 맞는 기술적 실행 관례를 선택할 수 있다.
- YAGNI (You Ain’t Gonna Need It): MSA가 좋다고 해서 처음부터 서비스를 쪼개지 마라. 성급한 분리는 결합도만 높인다. 모놀리식으로 시작해 올바른 바운디드 컨텍스트(Bounded Context)를 찾는 것이 우선이다.
바운디드 컨텍스트란?
특정 도메인 모델이 유효하며, 유비쿼터스 언어가 일관된 의미를 유지하는 언어적, 논리적 경계이다.
예를 들어서 결제 서비스가 있다고 해보자. 여기서 User 도메인은 결제 주체이지만, 상담 서비스에서 User는 상담 대상이다. 그렇다면 결제 서비스와 상담 서비스는 서로 다른 바운디드 컨텍스트이다.
2. 유비쿼터스 언어: 개발자의 언어가 아닌 비즈니스의 언어로
클래스나 함수 이름을 짓는 데 고통받고 있다면, 그것은 영단어 선택의 문제가 아니라 유비쿼터스 언어의 부재일 가능성이 크다.
- 살아있는 문서: 용어 사전은
README.md처럼 코드와 가까운 곳에 관리되어야 한다. - 동사를 포함하라: 명사뿐만 아니라 비즈니스 행위를 나타내는 동사도 중요하다.
- 공통의 언어: 기획자, 디자이너, 개발자 모두가 같은 용어를 사용해야 한다. 코드에 이 용어가 반영되지 않는 순간, 커뮤니케이션 비용은 기하급수적으로 늘어난다.
3. 비즈니스를 모르면 월급도 없다: Brownfield와 도메인 지식
레거시 시스템(Brownfield)에서 작업할 때 가장 위험한 것은 비즈니스 로직을 모른 채 코드만 수정하는 것이다.
- 비즈니스 도메인 탐색: 우리가 어떤 비즈니스를 하고 있는지, 어디서 돈을 버는지(Core Subdomain) 파악해야 한다.
- 하위 도메인의 분류: 핵심, 지원, 일반 도메인을 구분하고 한정된 자원을 어디에 집중할지 결정해야 한다.
- 시각화의 힘: 비즈니스 플로우를 시각화 도구로 검증하고 공유하라. 모호했던 경계가 명확해진다.
4. 본격적인 문제 해결: 바운디드 컨텍스트와 외부 세계
문제를 해결하는 기본은 분할과 정복이다.
- 조직과 아키텍처: 팀 구조에 따라 바운디드 컨텍스트가 나뉘기도 하고(콘웨이의 법칙), 의도적으로 아키텍처를 나눠 팀 구조를 유도하기도 한다(역콘웨이의 법칙).
- 점진적 분리: 가장 작거나 영향력이 적은 곳, 혹은 가장 중요한 곳부터 하나씩 떼어내며 개선한다.
- 부패 방지 계층(ACL): 외부 시스템이나 레거시의 오염이 우리 모델에 침투하지 않도록 ACL(Anti-Corruption Layer) 과 DIP(Dependency Inversion Principle) 를 적극 활용하라.
마치며: 완벽한 설계는 없다
요구사항은 변하고 기획자도 모든 것을 알지 못한다. 완벽한 설계를 하겠다는 욕심을 버리고, 변화를 내재화하는 프로세스를 만들어야 한다. 일단 구현하고, 그 구현을 통해 얻은 지식으로 다시 리팩터링하는 것. 그것이 실질적인 의미의 DDD이다.