데이터가 아니라 업무 문제를 설계의 중심에 두는 방법. 무엇을 개선하려는 것인지는 반대편을 보면 분명해진다.
데이터 주도 설계의 문제
데이터 주도 설계는 객체를 만들 때 무엇을 가질지부터 정하는 방식이다. 그러면 그 데이터가 어디서 쓰일지 알 수 없으니 모든 필드에 접근자와 수정자를 열어두게 된다. 내부 구현이 밖으로 드러나 캡슐화가 깨지고, 손대는 모든 것과 강하게 결합된다. 객체는 데이터 보관함이 되고 로직은 전부 밖으로 빠져나간다.
유비쿼터스 언어
DDD의 실천적 요구는 하나로 모인다. 업무를 아는 사람과 코드를 쓰는 사람이 같은 말을 쓰는 것이다. 대화에서도 문서에서도 코드 안에서도 똑같은 단어를 쓴다. 기획자가 “정산”이라고 부르는 것을 코드에서 settlement가 아니라 calc라고 부르고 있다면 이미 어긋난 것이다. 개발자가 모델을 만드는 자리에 없었다면 그 모델은 구현에서 살아남지 못하므로, 모델링에 개발자가 참여해야 한다.
노리는 바는 도메인 지식이 코드에 그대로 담기는 상태다. 업무에서 쓰는 개념을 코드도 똑같이 말하게 만든다. 이 목표도 다른 설계 결정과 같은 곳으로 수렴한다. 모듈 간 결합도를 낮추고 모듈 내 응집도를 높이는 것이다. 도메인을 기준으로 묶으면 함께 바뀌는 코드가 함께 있게 되기 때문이다.
서비스를 나누는 경계
MSA와 함께 언급되는 이유도 여기 있다. 서비스를 어떻게 나눌지가 MSA에서 가장 어려운 문제인데, DDD는 그 경계를 도메인에서 찾자고 제안한다. 기술이 아니라 업무 단위로 나누면 서비스 하나가 하나의 일을 온전히 맡게 된다.