도메인 주도 개발 시작하기

개인적으로 새로운 주제에 대한 책을 보는 것도 좋아하지만, 한번 봤던 주제, 이미 사용하면서 조금은 알고 있다고 생각하는 주제에 대한 책도 다시 찾아서 읽어보는 것을 좋아하는데, 다시 보면 예전에 볼 때는 놓쳤던 것, 이해를 못하고 넘어갔던 것, 시간이 지나면서 잊었던 것들을  재확인할 수 있다.

오래전에 '도메인 주도 설계'를 봤을 때는 어렵게 읽은 기억이 있는데, 이 책은 주요 내용만 추려서 더 쉽게 풀어 쓰였고, 예제 코드들도 있어서 편하게 읽었다. 다만, 중반부의 리포지터리 구현 쪽 예제가 스프링과 JPA에 치중된 점은 아쉽지만, 이 점이 매우 마음에 드는 분도 있을 것이다.

 

10년쯤 전에 참여했던 프로젝트의 설계에 도메인과 I/O가 매우 잘 분리되어 있었고, 덕분에 많은 공부가 되었다. 하지만, DDD라는 개념이 있는지 모르는 상태에서 코드를 먼저 접했고, 나중에 책을 찾아서 봤다.

이렇게 도메인 분리가 잘된 프로젝트 경험이 있는 상태에서 DDD를 처음 접하면 어떤 부분은 당연한 소리를 멋있게 풀어낸 거 같고, 어떤 부분은 조금 뜬구름 잡는 것 같은 그런 느낌으로 다가올 수 있다. 오래전에 나는 그랬었다. 응용을 먼저 접했어도, 잘 정리된 글로 그 응용의 이론적 배경을 읽어보는 것은 여러모로 도움이 되는 좋은 경험이라고 생각한다.

 

참여 중인 프로젝트에 DDD에서 본 내용들을 도입하려고 할 때, DDD에서 이야기하는 개념들을 한 번에 모두 도입하려고 하면 생각보다 어려울 수도 있다. 하나씩 점진적으로 하는 것이 좋은데, 도메인에 종속되는 비즈니스 로직을 I/O와 분리하는 것을 첫 마일스톤으로 잡는 것이 좋다고 생각한다. 일단, 도메인 로직이 I/O에서 독립적으로 구성되면 추가 개선은 생각보다 수월하다.

 

이 글을 적으면서 보니 '도메인 주도 설계' 번역서가 최근 eBook으로 출간되었다. 출간된 지 10년이 넘은 기술서가 eBook으로 나오다니, 조만간 다시 읽어볼 예정이다.

 

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=292507917 

[전자책] 도메인 주도 개발 시작하기

처음부터 완벽한 개념 모델을 만들기보다는 전반적인 개요를 알 수 있는 수준으로 개념 모델을 작성해야 한다. 프로젝트 초기에는 개요 수준의 개념 모델로 도메인에 대한 전체 윤곽을 이해하는 데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜 나가야 한다.
...
도메인 객체가 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해 주어야 한다. 즉 생성자를 통해 필요한 데이터를 모두 받아야 한다.
...
알맞은 영단어를 찾는 것은 쉽지 않은 일이지만 시간을 들여 찾는 노력을 해야 한다. 한영사전을 사용해서 적당한 단어를 찾는 노력을 하지 않고 도메인에 어울리지 않은 단어를 사용하면 코드는 도메인과 점점 멀어지게 된다. 그러니 도메인 용어에 알맞은 단어를 찾는 시간을 아까워하지 말자.
...
도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다.주요 도메인 요소 간의 관계를 파악하기 어렵다는 것은 코드를 변경하고 확장하는 것이 어려워진다는 것을 의미한다. 상위 수준에서 모델이 어떻게 엮여 있는지 알아야 전체 모델을 망가뜨리지 않으면서 추가 요구사항을 모델에 반영할 수 있는데, 세부적인 모델만 이해한 상태로는 코드를 수정하는 것이 꺼려지기 때문에 코드 변경을 최대한 회피하는 쪽으로 요구사항을 협의하게 된다.
...
애그리거트를 영속화할 저장소로 무엇을 사용하든지 간에 애그리거트의 상태가 변경되면 모든 변경을 원자적으로 저장소에 반영해야 한다. 애그리거트에서 두 개의 객체를 변경했는데 저장소에는 한 객체에 대한 변경만 반영되면 데이터 일관성이 깨지므로 문제가 된다.
...
도메인 로직을 도메인 영역과 응용 서비스에 분산해서 구현하면 코드 품질에 문제가 발생한다. 첫 번째 문제는 코드의 응집성이 떨어진다는 것이다. 도메인 데이터와 그 데이터를 조작하는 도메인 로직이 한 영역에 위치하지 않고 서로 다른 영역에 위치한다는 것은 도메인 로직을 파악하기 위해 여러 영역을 분석해야 한다는 것을 의미한다.두 번째 문제는 여러 응용 서비스에서 동일한 도메인 로직을 구현할 가능성이 높아진다는 것이다.
...
응용 서비스에서 애그리거트 자체를 리턴하면 코딩은 편할 수 있지만 도메인의 로직 실행을 응용 서비스와 표현 영역 두 곳에서 할 수 있게 된다. 이것은 기능 실행 로직을 응용 서비스와 표현 영역에 분산시켜 코드의 응집도를 낮추는 원인이 된다.
...
한 애그리거트에 넣기 애매한 도메인 기능을 억지로 특정 애그리거트에 구현하면 안 된다. 억지로 구현하면 애그리거트는 자신의 책임 범위를 넘어서는 기능을 구현하기 때문에 코드가 길어지고 외부에 대한 의존이 높아지게 되며 코드를 복잡하게 만들어 수정을 어렵게 만드는 요인이 된다. 게다가 애그리거트의 범위를 넘어서는 도메인 개념이 애그리거트에 숨어들어 명시적으로 드러나지 않게 된다.
...
여러 하위 도메인을 하나의 바운디드 컨텍스트에서 개발할 때 주의할 점은 하위 도메인의 모델이 섞이지 않도록 하는 것이다. 한 프로젝트에 각 하위 도메인의 모델이 위치하면 아무래도 전체 하위 도메인을 위한 단일 모델을 만들고 싶은 유혹에 빠지기 쉽다. 이런 유혹에 걸려들면 결과적으로 도메인 모델이 개별 하위 도메인을 제대로 반영하지 못해서 하위 도메인별로 기능을 확장하기 어렵게 되고 이는 서비스 경쟁력을 떨어뜨리는 원인이 된다.

-알라딘 eBook <도메인 주도 개발 시작하기> (최범균 지음) 중에서