결론
위 사진은 필자의 개인 깃허브에 작성해둔, 만들면서 배우는 클린 아키텍처 라는 책을 읽고 각색(?)해서 작성한 예제 프로젝트이다.
살펴보다보면, 꽤 특이한 패키지 이름이 보일 것이다. 이름하여, pojo.
회사 선임분과 책에 대한 나의 생각과 이런저런 이야기를 나누다보니 여러 이야기를 들을 수 있었고, 현재 학습과 가장 연관있고 직관적인 이름이어서 선택했다.
발단
물론, 가장 처음에 붙여둔 이름은 아래 사진과 같이 domain 이었다.
하지만 이름을 domain으로 붙여놓고 계속해서 보다보니 헷갈리기 시작했다.
domain이면.. entity 역시 domain 패키지에 있어야 하는 것이 아닐까? domain.entity, domain.model 이라고 하면 그럴듯해 보이지 않나?
그래서 아래 사진처럼 구조를 바꿨다. 그런데.. 지켜보다보니 뭔가 기시감이 느껴진다. 그래서 이 부분에 대해 고민하다가 점심시간을 이용해 선임분께 질문했다.
위 사진처럼 domain 패키지 안에 model, entity로 나누어 패키지를 구성해보았는데, 어떻게 생각하시나요? 라고. 그랬더니 여러 가지 이야기들을 들을 수 있었다. 아래에 기억을 더듬어가며 했던 대화들을 복원해봤다.
도메인이 뭔가요?
선임분(이하 A) : 도메인이 뭔가요?
나 : 네?
A : 도메인은 굉장히 다양한 의미로 사용되는 단어이기 때문에 '잘' 정의하고 사용해야 해요. 사실 회원에 대한 기능을 모아두면 회원 도메인이 될 수 있고 기능별로 분리하면 그 역시 기능도메인이 될 수 있어요. 그런거라면 패키지부터 기능별로 모두 분리해야겠죠.
application.changenickname,application.registeruser... 등으로 말이죠. 제일 먼저 든 생각은, 저domain이라는 녀석이 뭘 의미하는거지? 였어요.나 : 아, 여기서는 비즈니스 로직을 수행하는 객체를 말하고 있어요.
A : 그렇다면 이녀석은 사실
POJO인 거네요.나 : 네?
듣고보니 그렇다. domain model이라고 부르는 것들은 사실 POJO와 다를 바가 없던 것이었다. 괜히 model이니 entity이니 고상한척 이름을 붙이려고 했다는 사실을 깨달았다. 그리고 여기에 얽힌 이야기도 조금 들을 수 있었다.
과거
과거에는 POJO만 모아놓은 domain 패키지가 유행했다고 한다.
생각해보면, 당시에는 배포가 지금처럼 간단하지도 않았을거고(지옥의 배포) IDE가 지금처럼 발달하지도 않았을 것이다.
그 결과, 파일들을 주고 받을 때 그냥 패키지 단위로 복사해서 툭 하고 던져주면 되는 POJO가 유행할만 하다는 생각이 들었다. POJO는 다른 어떤 외부의 것에도 의존하지 않기 때문에, 그들끼리만 있어도 충분히 잘 동작하니까.
패키지에 대한 생각
그리고 아래와 같은 말씀도 해주셨다.
소프트웨어 공학에서의 패키지 → 패키지끼리는 독립적이어야 한다. 패키지끼리 따로 떼내도 동작해야 한다.
자바에서의 패키지 → 단순 디렉토리 구조.. 네임스페이스, 코드의 묶음과 유사하다고 볼 수 있다.
단순하게 생각해도, 우리들은 프로젝트를 구성할 때마다 디렉토리(또는 패키지)에 이름을 붙이고 그에 관련있는 것들끼리 모아놓는다. 그리고 파일 정리를 잘 했다고 생각하곤 한다(일단 나부터도 그랬다..).
하지만 소프트웨어 공학에서의 패키지 관점에서 생각해보면, 내가 생각한 구조(domain 패키지 내부에 entity와 model 패키지가 위치하는)는 전혀 독립적이지 않았다.
위 사진만 보더라도, javax.persistence.* 패키지가 여럿 import 되어 있는 것을 볼 수 있다. 즉, UserEntity는 domain 이라는 패키지에 묶여서 독립적으로 떼어놔도 동작할 수 있는가? 라고 물으면 '아니오' 라고 답할 수 밖에 없는 것이다.
그런 관점에서 바라봤을 때, 제일 처음 결론과 같은 패키지 구조가 탄생한 것이다.
정리
만들면서 배우는 클린 아키텍처라는 책을 읽고 여러 생각을 해봤는데, 현재 프로젝트에서 핵심 가치가 무엇인지 생각해보는 게 중요한 것 같다. 정말 딱딱 맞아 떨어지는 완벽한 구성을 가진 아키텍처도 좋지만, 어느정도 개발 편의성과 타협하는 것도 좋지 않을까? 라는 생각도 해본다.
실제로 책에서 제시하는 방식을 사용해보면서 알 수 있었던 것이 있다. JPA Entity와 POJO가 분리되어 있고 비즈니스로직은 모두 POJO에서 수행하는 것은 정말 깔끔한, 비즈니스 로직만을 구현한 POJO를 얻을 수 있지만 JPA에서 지원해주는 여러가지 이점(또는 지옥으로 이끄는 단점)을 누릴 수 없게 된다는 것이다. 이래서 트레이드오프가 중요하다고 하는 것 같다.
