엔티티 VS 서비스

포트폴리오를 리팩토링 하고 있다. 거의 반년 전 포트폴리오인데, 반년 지났다고 코드가 마음에 안든다. 나름 열심히 레이어를 나눴는데 영 아니다 싶은 것도 많다. 가장 큰 이유는 객체지향을 제대로 적용해보고 싶어서다. 그런데 문제는 엔티티(엔티티 클래스)가 어느 선까지 담당해야 하는가?

엔티티와 서비스(유즈케이스)는 어느 선 부터 어느 선 까지 담당해야 하는지 가늠하기가 애매하다. 물론 복잡해지면 결국 서비스 레이어가 담당해서 처리하는 부분이 늘어날 것이다. 어느 한 엔티티가 담당하기 힘들어 질테니 말이다. 하지만 포트폴리오 사이즈는 그렇게 확장하기 힘들다.

이 구분이 애매해서 검색해 보았다. 

 

일단 도메인이 비즈니스 로직의 주도권을 가지는 것을 도메인 주도라고 한다. 이 경우 서비스의 많은 로직이 엔티티에 위치하고 서비스는 엔티티 호출의 역할 정도이다. 반대로 엔티티는 get, set 정도만 제공하고 서비스에 비즈니스 로직을 두어도 된다. 엔티티가 핵심 로직을 지닌 객체가 되느냐, 아니면 자료구조 역할에 충실하느냐가 핵심이다.

엔티티 하나에서 처리가 되면 엔티티 메서드로 처리하고 엔티티 단독으로는 곤란해서 협동이 필요하다면 서비스로직에서 협동해 처리하는 방식도 적당할 것 같다. 하지만 리팩토링은 엔티티가 get, set 정도만을 담당하는 구조로 만들고자 한다. 서비스 레이어에서 처리하는게 '분리'라는 측면에 대해 감을 잡는 데 적당 할 것 같기 때문이다.

어떤 방식이 프로젝트에 적합할지 가늠하는 건 경험이 더 필요하다. 아예 몰랐으면 모르겠는데 나름 아는 것이 생기니 이 방식이 맞나하는 의구심 부터 생긴다. 더닝 크루거 효과에 나오는 절망의 계곡을 열심히 빠져나오려고 하는 것이라 여기자.