🏷️비즈니스 로직을 어느 쪽에서 구현해야되는가에 대한 관심을 가지게 된 계기
현재 인프런 김영한 강사님의 스프링 강의 중 『실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발』내용에 대해서 복습을 하고 있다. 강의를 따라서 코드를 치기만 한다면 그것이 과연 내 것이 될까 싶어 요구사항을 직접 개발해보기로 하였다. 강의 내용 중에 상품 관련 요구사항을 구현하는 중에 Domain에서 비즈니스 로직을 개발하는 부분과 Service에서 비즈니스 로직을 개발하는 부분에서 막혔고 이 두 방식의 차이점을 알아보고자 작성하게 되었다.
🏷️Domain에서 비즈니스 로직 개발 vs Service에서 비즈니스 로직 개발
도메인이 비즈니스 로직의 주도권을 가지고 개발하는 것을 도메인 주도 설계라고 한다. 이렇게 해두면 서비스의 많은 로직이 엔티티로 이동하고, 서비스는 엔티티를 호출하는 정도의 얇은 비즈니스 로직을 가지게 된다.
반대로 엔티티는 단순히 Getter/Setter만 제공하고 서비스에 비즈니스 로직이 모두 담겨 있어도 된다. 이렇게 되면 서비스 로직이 커지고 엔티티는 단순히 데이터를 전달하는 역할만 담당하게 된다.
도메인 객체도 결국 자바 객체이기 때문에 속성과 행위를 가지고 있어야 한다. 해당 도메인 객체에 대한 비즈니스 로직이 있다고 하면 서비스 계층에 작성하는 것보다 해당 도메인에 작성하는 것이 좋다. 그러나 그렇다고 해서 모든 비즈니스 로직을 도메인 객체 쪽에 개발하는 것이 좋은 것은 아니다. 여러 종류의 도메인 객체를 조합해야 하거나 도메인 객체와 결합도가 떨어지는 비즈니스 로직 혹은 리포지토리와 직접적으로 관련을 맺게 되는 로직(회원가입, 로그인 등) 등은 서비스 계층에 작성하는 것이 좋다.
결과적으로 개발 시 비즈니스 로직을 Service Layer 한 곳에다 전부 두기보다는 도메인에도 기능을 정의하는 방식을 사용해야 한다는 것을 알고 넘어가게 되었다.
🏷️참고한 내용들
https://mangkyu.tistory.com/160
https://www.inflearn.com/questions/250279/service%EC%99%80-entity-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EB%A1%9C%EC%A7%81%EC%97%90-%EA%B4%80%ED%95%B4
https://www.inflearn.com/questions/117315/%EB%B9%84%EC%A7%80%EB%8B%88%EC%8A%A4-%EB%A1%9C%EC%A7%81%EA%B5%AC%ED%98%84-entity-vs-service
