적절한 분리를 통해 단일 책임 원칙 구현

• Single Responsibility Principle
• 하나의 모듈은 한가지 책임을 가져야 한다.
  • 하나의 모듈이 바뀌어야 하는 이유는 한 가지여야 한다.

UserService

• UserService 에 JDBC Connection 의 메서드를 직접 사용하는 트랜잭션 코드가 있을 때를 생각해보자.
• UserService 의 책임
  • 어떻게 사용자 레벨을 관리할 것인가.
  • 어떻게 트랜잭션을 관리할 것인가

<aside> 📌

두가지 책임 → UserService 가 수정되는 이유도 두가지

</aside>

• 사용자 관리 로직 변경: ex. 사용자 레벨 업그레이드 정책

  • UserService 코드를 수정해야 한다.

• 서버 환경 변화: ex. JDBC 에서 JTA 로 변경

  • UserService : 직접 노출한 Connection 오브젝트 트랜잭션 메서드 대신 JTA 의 UserTransaction 오브젝트를 이용하도록

  ⇒ 변경의 이유가 두가지가 되기 때문에 단일 책임 원칙을 지켰다고 볼 수 없다.

트랜잭션 서비스의 추상화 적용 이후

• DI 를 통해 외부에서 트랜잭션을 제어하도록

• UserService 가 바뀔 이유는 한 가지 뿐이다.

  • 사용자 관리 로직이 바뀌거나 추가

• 아래와 같은 이유로 UserService 코드를 수정할 이유가 사라졌다.

1. 트랜잭션 기술/사용할 서버 환경 변경

2. UserDao 의 데이터를 가져오는 테이블 변화

3. UserDao 의 구현 기술이 JDBC 에서 JPA 로 변화

   ⇒ 단일 책임 원칙을 충실하게 지키고 있다.