[TIL] 3계층 구조의 단일 책임 원칙(SRP) 위배

목차

• 1. 도메인-3계층 구조의 SRP 위배
• 2. Controller에서 여러 Service 호출
• 3. 마치며

개요

프로젝트에서 service단을 작성하던 중 단일 책임 원칙에 대해 생각했다.

현재 상황에서 어떻게 하면 단일 책임 원칙을 위배하지 않고 코드를 작성할 수 있을지에 대해 고민했다.

내가 현재 상황에서 내린 결정에 대해 서술하고자 한다.

 

 도메인-3계층 구조의 SRP 위배 

현재 계층 구조

controller

 

service

현재 service의 내용을 작성하기 위해서는 1, 2번의 예외처리 때문에 팀원 구인글의 repository 호출해와야 한다. 이 과정에서 하나의 service에 하나의 repository를 호출해야되는 단일 책임 원칙이 위배된다.

 

 Controller에서 여러 Service 호출

결론은 controller에서 여러 service를 호출해야 된다고 결정했다.

하지만, 그렇게되면 contoller에서도 단일 책임 원칙을 위배하지 않는가?

어느 정도는 맞다. 이는 단일 책임 원칙 위배처럼 보일 수 있다. 그러나, Controller의 역할은 요청을 처리하고 적절한 Service를 호출하여 응답을 반환하는 것이므로, 여러 Service를 호출하는 것은 Controller의 역할에 부합한다.

즉, 역할을 중심으로 단일 책임 원칙을 해석하는 것이 현실적인 해결책이다.

 

내가 이 결론을 내린데는 다음과 같은 이유가 있다.

1. service의 책임이 명확해짐
2. 재사용성이 증.
3. 하나의 service가 너무 많은 역할을 하게 되면 유지보수가 어려워짐
4. 도메인 간 결합도를 낮추기 위해

현재 서비스가 완벽하게 기획과정을 거치지 못했기 때문에 계속 바뀔 가능성이 있다. 이를 위해서 유지보수가 어려워지지 않도록 고려했다. 또한, 도메인 간 결합도가 높아질 경우 관련 로직이 변경되면 service에도 영향을 미쳐 함께 변경해줘야 한다. 이렇게 되면 다른 도메인의 entity가 변경될 경우 내 코드도 함께 맞춰서 변경해줘야 한다. 이를 예방하기 위해 지금의 방식을 채택했다.

 

 마치며

비즈니스 로직을 조합하는 곳이 어디인지가 핵심이다. “어떤 방식이 무조건 정답이다”는 아니지만, “비즈니스 로직을 어디에서 조합하는 것이 더 자연스러운가?”가 설계를 결정하는 기준이 되어야 한다.

다음은 어떤 상황에서 어떤 방식이 더 적절한가에 대한 내 결론이다.

• Controlelr에서 여러 Service를 호출하는 방식

→ Service들이 독립적인 도메인 단위로 동작해야 할 때 적합

→ 트랜잭션 관리가 필요 없는 단순 조회 API에 적합

→ 여러 도메인의 데이터를 단순히 합치는 경우

• Service에서 여러 Repository를 호출하는 방식

→ 하나의 비즈니스 로직 단위에서 여러 데이터를 조합할 때 적합

→ 트랜잭션을 하나로 묶어야 할 경우 적합

→ 특정 도메인 간의 강한 연관이 있는 경우