[토비의 스프링vol.1 5장] 서비스 추상화

5장 서비스 추상화

트랜잭션 서비스 추상화

작업 중 예외가 발생해 완료 되지 않았다면 ? -> 작업이 시작되지 않은 것처럼 초기 상태로 되돌려 놓아야한다. 이것이 트랜잭션이다.

트랜잭션 : 더 이상 나눌 수 없는 단위 작업 (원자성)

트랜잭션 경계 설정

• 트랜잭션 롤백 : 취소 작업
• 트랜잭션 커밋 : 작업 확정시킴
• 트랜잭션 경계 : 트랙잭션이 시작되고 끝나는 위치

롤백을 위해서는 여러 개의 작업을 1개의 트랜잭션으로 관리 해야 함

트랜잭션 동기화

JDBC 기준, 트랜잭션 유지하려면 시작-끝까지 같은 Connection 유지
-> Connection 파라미터로 전달하면 데이터 엑세스 기술에 독립적 X -> JPA 등으로 구현 방식 변경하면 인터페이스 DAO 다 수정해야함(DI 적용 안 되는 것)

-> 동기화 통해 파라미터 제거

• 트랜잭션을 시작하기 위해 만든 Connection 오브젝트를 특별한 저장소에 보관해두고, 이후에 호출되는 DAO의 메소드(특별한 저장소 예시) 에서 저장된 Connection을 가져다가 사용하게 하는 것
• 작업 쓰레드마다 Connection 오브젝트 독립적인 관리 -> 멀티쓰레드 환경에서 충돌 X
• 파라미터를 통해 Connection 오브젝트 일일이 전달 필요 X

->JDBC Connection 을 이용한 트랜잭션 방식인 로컬 트랜잭션으로는 한 개 이상의 DB를 하나의 트랜잭션으로 관리 못함
why? 로컬 트랜잭션의 하나의 DB Connection 에 종속되기 때문
-> 글로벌 트랜잭션 사용해야 여러 개의 DB가 참여하는 작업을 하나의 트랜잭션으로 만들 수 있음
-> JTA, JDBC, 하이버네이트 등 마다 트랜잭션 관리 API가 독자적임

SQL 이용이라는 '공통점' 뽑아내서 DB종류와 관계 없이 데이터 엑세스 가능한 게 JDBC(추상화 기술)


-> 트랜잭션 경계설정의 공통점 모아서 추상화된 트랜잭션 관리 계층 만들 수 있음

트랜잭션 추상화

• 각 기술의 트랜잭션 API 이용하지 않아도, 일관된 방식으로 트랜잭션 제어하는 트랜잭션 경계설정 작업 가능해짐
• PlatformTransactionManager : 스프링이 제공하는 트랜잭션 경계 설정 위한 추상인터페이스
• 각 기술에서 위 인터페이스 구현 클래스를 만들어서 사용

서비스 추상화와 단일 책임 원칙

• 서비스 추상화는 로우레벨의 트랜잭션 기술과 API의 변화에 상관없이 일관된 API를 가진 추상화 계층 도입한다.

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

트랜잭션의 추상화 : 애플리케이션의 비즈니스 로직과 그 하위에서 동작하는 로우레벨의 트랜잭션 기술이라는 아예 다른 계층의 특성을 갖는 코드를 분리 한 것
<-> 수평적 분리(계층)

단일 책임 원칙

• 하나의 모듈은 한 가지 책임만 가짐. 하나의 모듈이 바뀌는 이유는 한 가지

단일 책임 원칙 장점

• 변경 필요시 수정 대상 명확
• 결합도 낮아져 서로의 변경이 영향 주지 않음
• 스프링이 지원하는 DI와 싱글톤 레지스트리로 인해 테스트 자동화 편리해짐

-> 잘 지키기 위해선?

• 인터페이스 도입하고 이를 DI로 연결
  

결과적으로 개방 폐쇄 원칙 잘 지킴, 모듈 간 결합도 낮아짐, 응집도 높아짐

DI가 없었다면, 인터페이스를 도입해서 추상화를 했더라도 적지 않은 코드 사이의 결합이 남게 됨
ex) PlatformTransactionManager 라는 인터페이스 제공 메소드 적용했지만, new DataSourceTransactionManger() 라는 구체적인 의존 클래스 정보가 드러나는 코드

테스트를 위한 서비스 추상화

• 테스트 하기 어려운 JavaMail과 같은 기술에 서브스 추상화 기술 적용 가능

ex) 스프링이 제공하는 MailSender 인터페이스 사용하여 사용하여 DI

테스트 대역

• 테스트 대상이 사용하는 의존 오브젝트를 대체할 수 있도록 만든 오브젝트
• 테스트 대상 객체가 원활하게 동작할 수 있도록 도우면서 테스트를 위해 간접적인 정보 제공

목 오브젝트

• 테스트 대역 중에 테스트 대상으로부터 전달받은 정보를 검증할 수 있도록 설계된 것