update() 메소드는 repository에 둬야할까, service에 둬야할까?

먼저 응집력(cohesion)과 책임 분리(separation of concerns)에 대해 알아보자.

 

응집력 (Cohesion) 

응집력은 클래스들이 얼마나 관련된 기능들을 수행하는지에 대한 정도이다. 동일한 책임을 가지는 메소드들이 한 클래스나 패키지에 모여 있을 때 응집력이 높다고 한다.

 

책임 분리 (Separation of Concerns)

시스템의 관심사를 분리하는 원칙이다. 이를 통해 코드의 재사용성을 높이고 유지보수를 용이하게 한다.

* 관심사의 분리, 단일 책임의 원칙

 

Repository vs Service 패키지

Repository 패키지

주로 데이터 접근을 담당한다. 여기에는 주로 데이터베이스 CRUD 연산을 수행하는 메소드들이 있다.

 

Service 패키지

비즈니스 로직을 처리한다. 여기에는 여러 데이터 접근 연산 조합이나 복잡한 비즈니스 규칙을 처리하는 메소드들이 있다.

여러 리포지토리 메소드를 호출하여 필요한 작업을 수행한다. 

 

나는 여기서 "데이터 접근 연산 조합"에 궁금증이 들었다.

데이터 접근은 repository 패키지 내부의 메소드들의 역할 아닌가?
데이터 접근 연산과, 데이터 접근 연산 조합은 어떻게 다른가?

 

데이터 접근 연산 

데이터 접근 연산은 데이터베이스와 직접 상호작용하여 데이터를 CRUD(생성, 읽기, 업데이트, 삭제)하는 작업을 의미한다. 이 작업들은 주로 리포지토리 계층에서 수행된다. 

 

데이터 접근 연산의 조합

데이터 접근 연산의 조합은 여러 개의 데이터 접근 연산을 하나의 비즈니스 로직으로 묶어 처리하는 것을 의미한다. 이 작업은 주로 서비스 계층에서 수행된다. 

 

즉, repository 계층의 메소드는  save()와 같이 단순한 CRUD 작업만을 수행한다. 그리고 서비스 계층의 메소드는 repository 계층에서 만든 단순 CRUD 메소드들을 조합하여, 비즈니스 로직을 꾸려가는 것이다.

 

---

Repository 패키지에 update()를 둘 경우

장점

• 데이터 접근에 대한 모든 책임이 한 곳에 모이게 되어 응집력이 높아진다.
• 데이터베이스와의 상호작용에 대한 코드를 한 곳에서 관리한다.

단점

• 비즈니스 로직과 데이터 접근 로직이 섞일 수 있다.
• 데이터 업데이트 과정에서 추가적인 비즈니스 로직이 필요할 경우, 리포지토리 계층에서 이를 처리하는 것이 부적절할 수 있다.

 

Service 패키지에 update()를 둘 경우

장점

• 비즈니스 로직과 데이터 접근 로직을 명확히 분리할 수 있다.
• 업데이트 과정에서 새로운 비즈니스 로직을 추가할 수 있다.

단점

• 데이터 접근과 비즈니스 로직이 분리됨에 따라 응집력이 약간 떨어진다.
• 서비스 계층이 너무 비대해질 수 있다.

 

결론

일반적으로 update() 메소드는 서비스 패키지에 두는 것이 더 좋은 방법이다. 이는 비즈니스 로직과 데이터 접근 로직을 명확히 분리하고, 비즈니스 로직을 쉽게 확장할 수 있기 때문이다. 데이터베이스에 접근하는 코드는 리포지토리 패키지에 두고, 서비스 패키지에서 이러한 리포지토리를 호출하여 비즈니스 로직을 처리하는 구조가 바람직하다.