10. 도메인
소프트웨어 공학에서 말하는 '도메인'은 애플리케이션이 해결하고자 하는 문제 영역을 의미한다. 다시 말하면 사용자들이 겪는 문제 영역이 바로 도메인이다. 그리고 문제 영역이 곧 비즈니스 영역이므로 도메인은 비즈니스 영역을 의미하기도 한다. 따라서 도메인은 문제 영역이자 비즈니스 영역이다.
같은 맥락으로, 개발자의 역할은 단순히 요구사항에 맞는 애플리케이션을 개발해 주는 것이 아니라 고객이 겪는 문제 상황을 소프트웨어로 해결해주는 사람이라고 볼 수 있다. 즉, 개발자는 도메인을 분석하고, 고객이 겪는 문제를 인지하고, 이에 맞는 도메인 솔루션을 개발해줄 수 있어야 한다. 개발만 잘한다고 좋은 개발자가 아닌 것이다 :)
스프링 같은 프레임워크나 JPA는 애플리케이션의 핵심이 될 수 없다. 때문에 '스프링이나 JPA 같은 프레임워크를 사용해서 개발한다'라는 것을 전제로 설계하는 것을 피해야 한다. 프로젝트 결과물을 보았을 때 "이 프로젝트는 스프링과 JPA를 사용하는 프로젝트네" 라는 반응이 나오는 설계를 피해야 한다. "이 프로젝트는 이런 도메인을 다루고 있네" 라는 반응이 나올 수 있도록 설계해야 한다. 프로젝트 설계는 도메인을 설명할 수 있어야 한다. 아키텍처만 봐도 어떤 도메인을 다루는지 알 수 있게 만들어야 한다.
애플리케이션에서 도메인을 제외한 다른 부분은 도메인을 해결하기 위한 도구이자 수단일 뿐이다. 따라서 중요한 것은 사용자에게 어떤 형태로 비즈니스 가치를 전달할 수 있는가, 그리고 그러기 위한 도메인 분석과 도메인 설계다.
도메인 모델과 영속성 객체
"도메인 모델과 영속성 객체는 구분해야 하는가?"
- 구분하였을 때
- 작성해야 하는 코드의 양이 증가한다
- 단순히 클래스 두개가 생기는 것이 아니라 도메인 모델을 영속성 객체로 혹은 영속성 객체를 도메인으로 변경해주는 로직이 추가된다.
- 도메인과 영속성 라이브러리가 분리되어 추후에 DBMS를 변경한다하여도 변경되는 코드가 적을 것이다.
- 통합하였을 때
- 작성해야 하는 코드의 양이 줄어든다
- 도메인이 영속성 라이브러리에 강결합된다
코딩해듀오 프로젝트 전까지는 도메인 모델과 영속성 객체를 통합한 상태로 사용했었다.
하지만 프로젝트 하면서 켈리가 두가지를 구분하여 코드를 작성해보자는 의견을 내어 프로젝트에서는 도메인 모델과 영속성 객체를 구분하여 코드를 작성했었다. 처음에는 도메인 모델 코드도 작성하고 영속성 객체 코드도 작성해야 하는게 너무 번거로웠다. 코드 짜보면 알겠지만 꽤 많은 보일러 플레이트 코드가 생긴다. 하지만 점점 도메인의 역할이 명확해지고, 또 도메인 스스로 하는 일이 많아지면서 두 개를 구분한 것이 꽤 괜찮은 선택이었다는 생각이 들었다.
레벨 4 미션 진행하면서도 도메인 모델과 영속성 객체를 구분하여 코드를 짰었는데, 다른 크루 코드를 구경하면서 통합한 코드가 오히려 더 어색하다고 느꼈다. 앞으로도 이 둘을 구분하여 코드를 짤 것 같다.