토비의 스프링 - 5.3 서비스 추상화와 단일 책임 원칙

5.3.1 수직, 수평 계층구조와 의존관계

• 추상화 기법을 이용하면 특정 기술환경에 종속되지 않는 포터블한 코드를 만들 수 있음
• UserDao는 데이터 액세스 로직임
• UserService는 사용자 관리 업무의 비즈니스 로직임
• UserDao와 UserService 분리는 같은 애플리케이션 계층에서의 수평적 분리임
• UserDao와 UserService는 인터페이스와 DI를 통해 연결됨으로써 낮은 결합도를 지님
• 즉, 독립적으로 확장 가능
• 마찬가지로 UserService와 트랜잭션 기술은 PlatformTransactionManager 인터페이스를 사용했기 때문에 독립적인 코드임
• 단, UserService와 PlatformTransactionManager는 로우 계층의 수직적 분리임
• 하지만, DI를 통한 수평적, 수직적 분리는 낮은 결합도로 인해 각각 자유롭게 확장 가능
• 스프링의 DI가 중요한 역할을 해 분리가 가능한 것임

5.3.2 단일 책임 원칙(ISP)

• 하나의 모듈이 바뀌는 이유는 한 가지여야 함
• UserService 내부에서 Connection 메소드를 직접 사용하는 트랜잭션 코드는 두 가지 책임이 있음
• 첫 번째는 사용자 관리 로직이 변경 됐을 때임
• 두 번째는 로직이 변경되지 않지만 JDBC가 아닌 JTA, 하이버네이트와 같은 구현 기술 변경일 때임
• 이 두 가지 책임이 있으므로 단일 책임 원칙에 위반됨
• PlatformTransactionManager인스터페이스 사용으로 구체적 구현 클래스는 XML에서 정의해 주입함으로써 UserService는 사용자 관리 로직 변경이 됐을 때만 수정됨
• 즉, 트랜잭션 서비스의 추상화 및 DI를 바탕으로 단일 책임 원칙으로 변경됐음
• 단일 책임 원칙을 적용하면, 변경이 필요할 때 수정 대상이 명확해 짐

💡 결론, DI가 짱이다.