독후감 - DDD Start!

톡특한 책이다. 1장부터 개념보다는 소스가 훅 들어와서 당혹스러웠다.

1장에 소스가 들어와서 안될 것은 없지만, DDD 입문서인데 DDD에 대한 정의는 없다는 게 의외다.

중간에 이 책의 대상 독자를 다시 찾아봤다. 요컨대 Spring/JPA는 눈에 익고 DDD를 들어는 봤으나 이해가 안되는 3~4년차 개발자라고 보면 되겠다.

또 하나. AGGREGATE를 동사형으로 애그리게이트라고 발음하면 안되고, 명사형은 [ǽgriget](애그리겥)으로 발음 한다면서 애그리거트라고 부르겠다니 완전 황당했다. 애그리거트라는 글자만 보면 자꾸 신경쓰여 찾아보니 책의 발음기호가 잘못 적힌 것이었다. 실제 발음기호는 [ǽgrigət].

어쨌든.

DDD를 아주 기초만 이해한 상태로 정리를 해보면,

클린코드나 객체지향 원칙을 따르면서 역할을 분리해 나가는 것과 크게 다르지 않다고 본다.

마침 ‘The Clean Architecture’의 번역글을 읽게 됐는데, 여기서도 비슷한 이야기를 하고 있는 것이다.

위 아키텍처의 세세한 부분은 모두 다르지만 매우 비슷하기도 하다. 이들은 모두 같은 목적을 갖고 있는데 바로 관심사의 분리다. 소프트웨어를 계층으로 나눔으로써 관심사를 분리한다. 그리고 모두 비즈니스 규칙을 위한 최소 하나 이상의 계층과 인터페이스를 위한 또 다른 계층을 두고 있다.

그러니까 저 다르면서 비슷한 아키텍처는 다들 고통속에 몸부림치다 이제 그만 열반에 들고자 만들어 낸 사리 쯤으로 봐야하는 건가.

나도 회사에서 (가능하면) 역할별로 클래스를 나누고 컨트롤러에서는 도메인 로직을 제거해나가고 있었는데, DDD에서는 그 역할을 보다 더 분명하게 분리해놨다.

표현 - 응용 - 도메인 - 리포지터리

(곧 떠날) 회사에 만들어 놓은(💩) 코드는 표현만 분리했지 나머지를 뭉뚱그려 놓은 모습이다. 책을 읽다보니 이렇게 네가지로 분리하는 것도 괜찮겠다는 생각이 든다. 애그리거트로 도메인 모델을 묶고, 애그리거트는 응용서비스에서 조합하며, 한 애그리거트에서 다루기 어려운 경우 도메인 서비스를 구성한다.

흠…대충 이런 느낌.

그런데 리포지터리와 모델 매핑 쪽이 이해가 잘 안된다.

리포지터리와 관련된 설명에는 (굳이 프레임웍 의존성을 피하지 않아도 된다면서) JPA를 예를 드는데, 어디까지 DDD와 관련있는지 잘 모르겠다.

그리고 PHP에서는 혹은 엘로퀀트에서는 저 예제를 어떻게 구현하게 될지 전혀 감이 안오는 상태. (JPA도 엘로퀀트도 잘 모르겠어서…)

그리고 현실적으로 단일 애그리거트만 다룰 일은 적을 것이고 수도 없는 bounded context간 통신을 해야한다. 그 더러운 꼴을 보자면 DDD로 개발한다고 뭐 더 좋아진다고 볼 수 만도 없겠지. 그냥 잘하는 사람이 DDD로 개발하면 결과가 좋고 잘하는 사람은 DDD로 안 해도 결과가 좋다는 염세적인 결론이 도출되기도 하지만, 다음 유행이 돌아 또 시스템을 갈아엎기 전까지 어떻게든 제품을 만들고 유지해야 입에 풀칠이라도 하고 살지 않겠는가.

아직 ACL, OHS가 나오는 도표라던가, PHP에서 AOP는 다들 얼마나 쓰고 있는지 궁금한 게 계속 꼬리를 문다.

응용서비스와 도메인서비스의 차이 중에 애그리거트 수정이 발생하면 도메인 서비스에 위치시킨다 정도는 기억해둘만 하다.(아니 겨우 이거 하나 기억했다는 말인가!)

가장 큰 질문은 이거다.

그러니까 이 책을 보고 DDD 감을 익힐 수 있단 말인가? 그 감은 내가 익힌 감이랑 같은 감인가?

그런데 DDD가 뭐더라?

(검색하다 깜짝 놀람. EXID의 노래 ‘덜덜덜’이라니…그러면서 나는 김혜림이란 이름도 기억하고 있다니…)

어쨌든 그동안 내가 희미하게나마 들어왔던 DDD는 이런 느낌이었는데,

이 책의 내용은 거대한 숲 안에서 작은 군락 정도만 표현한 것 같은 느낌을 지울 수 없다.

개발자들이 키보드에 손 올리고 신나게 개발할 준비를 하고 있을 때, ‘업무전문가’는 어디쯤 위치해야 하는가…