토비의 스프링 6 | 섹션 6 요약

Leehyoungwoo commented 1 month ago

서비스 추상화 (Service Abstraction)

서비스 - @Service

스프링에 대한 오해

~~스프링은 @Controller, @Service, @Repository만 기계적으로 찍어내는 개발 방법?~~
- 적어도 세가지 기능 구분으로 만들어야한다는 스프링의 가이드

스프링 애플리케이션 빈이 존재하는 계층 구조

3개의 전형적인 애노테이션을 사용하는 애플리케이션 빈의 위치
- @Controller - Presentation(Web, UI) Layer
  - 요새는 API 사용
- @Service - Business(Service, Application) Layer
  - 헥사 권한 아키텍처?
- @Repository - Persistence(Data Access, Infra) Layer

서비스는 일반적인 용어라 쓰이는 곳에 따라 다른 의미를 가짐

서비스는 클라이언트에게 서비스를 제공해주는 오브젝트나 모듈
- 서버라고 불러도 됨
- 모든 서비스는 클라이언트가 존재해야 함
서비스는 일반적으로 상태를 가지지 않음
- 상태 : 오브젝트가 그 안에 속성 값을 저장해두고 그걸 활용해서 기능을 수행하거나 돌려주는 것
- 상태없는 (stateless) 싱글톤 스프링 빈을 사용하기 적합
  - @Component, @Service
- 서비스가 상태를 가지고 있으면 모든 클라이언트의 모든 속성을 가지고 있으면 너무 방대해지고 두 개 이상의 클라이언트가 요청을 할때 꼬여버릴 수 있음
  - 상태를 가지는 서비스는 클라이언트의 세션 정보를 유지하거나, 특정 데이터의 상태를 유지할 필요가 있을 때 사용될 수 있음
  - 이러한 상태는 스레드-안전하거나 다중 클라이언트 환경에서 관리되어야 하며, 복잡도가 증가

서비스의 종류

애플리케이션 서비스
- 애플리케이션 계층에 있는 서비스
  - @Service 애노테이션을 붙임
  - 비즈니스 로직의 시작점, 종료의 경계에 있는 서비스
- 도메인 서비스
  - 도메인 모델 패턴을 이용해서 비즈니스 로직을 엔티티에 넣을때 특정 엔티티로 표현하기 힘든 서비스를 처리하기 위해 만듬
- 인프라 서비스
  - 서비스 추상화의 대상
  - 도메인/애플리케이션 로직에 참여하지 않는, 기술을 제공하는 서비스
    - 메일, 캐시, 트랜잭션, 메세징
      - 트랜잭션은 그 자체로는 애플리케이션에 로직을 갖지는 않지만 데이터 접근에 반드시 필요

애플리케이션 서비스 도입 - @Service

@Service 빈으로 구성
Application/Service 계층에 존재
애플리케이션/도메인 로직 - 도메인 오브젝트/엔티티 활용
인프라 서비스의 도움이 필요
가장 중요한 도메인/애플리케이션/비즈니스 로직
인프라 레이어에 존재하는 기술에 가능한 의존하지 않도록 만들어야 함
PaymentService -ExRatteService에 적용된 DIP

기술에 독립적인 애플리케이션 서비스

OrderService

데이터 엑세스 기술의 하나인 JPA에 의존
JPA를 사용하는 Repository 클래스에 의존
JPA Transaction Manager에 의존

Order

@Entity가 붙은 JPA 엔티티로 작성
컴파일 시점에만 JPA 라이브러리에 의존
클래스 코드에는 JPA 기술과 관련된 내용이 들어가지 않음
JPA를 사용하지 않으면 런타임에는 JPA 라이브러리에 의존하지 않음

Order에서 JPA 메타데이터 분리

애노테이션(@Entity)은 컴파일타임 라이브러리 의존성만 가짐
엔티티의 동작에는 영향을 주지 않기 때문에 엔티티 클래스를 다른 데이터 기술에서 사용해도 됨
그래도 제거하고 싶다면 외부 XML 디스크립터를 사용할 수 있음

/META-INF/orm.xml

여기에 작성해주면 됨

특정 기술(JPA)에 의존하지 않는 애플리케이션 서비스 만들기

JPA Repository - OrderRepository에 의존하지 않도록 변경
의존 관계 역전

트랜잭션 서비스 추상화 - PlatforeTransactionManager

Transaction은 데이터 기술에 따라 방법이 다르다

JDBC
- 오토 커밋 적용
  - 잘못하면 작업하는 여러개의 변경 작업이 하나의 트랜잭션으로 묶이지 않기 때문에 명시적으로 오토커밋을 끄고 수동 커밋
```
Connection con = ...
con.setAutiCommit(false)
...
con.commit();
```

JPA

EntityTransaction txn = entityManager.getTransaction();
txn.begin();
txn.commit(); or txn.rollback();

MyBatis
Jooq

추상화

구현의 복잡함과 디테일을 감추고 중요한 것만 남기는 기법
여러 인프라 서비스 기술의 공통적이고 핵심적인 기능을 인터페이스로 정의하고 이를 구현하는 어댑터를 만들어 일관된 사용이 가능하게 만드는 것이 서비스 추상화

개별 트랜잭션 기술의 디테일에 의존하는 클라이언트

모든 코드를 변경해야 함
추상화를 해야함
WorkFlow를 적용하는 방식이기 때문에 템플릿을 이용해야함
- PlatformTransactionManager<<interface>>
- 사용 방법이 완전 다르기 때문에 중간에 변환해주는 과정이 필요해 어뎁터를 둠
  - JpaTransactionManager, DataSourceTransactionManager
  - 각 기술을 사용하는 코드이면서 인터페이스를 구현한 코드를 가지고 처리

JDBC 데이터 엑세스 기술 - JdbcAsync/DataSourceTransactionManager

JDBC를 쓸 일이 없지 않나?
- 최적화된 방식으로 DB를 사용할 때 필요

JdbcClient

Jdbc의 기본 api만 사용하면 코드가 번거로움
- 예외 발생, 트랜잭션 걸기
템플릿을 사용하는게 기본 전제
Spring 6.1에서 추가
SQL을 사용하는 JDBC 데이터 처리 코드를 유연하게 작성하도록 도와줌
일종의 템플릿/콜백
스프링의 JdbcTemplate의 대체 기술

DataSourceTransactionManager

JDBC의 Connection을 이용하는 트랜잭션 매니저
Connection을 리턴하는 DataSource 오브젝트 필요

트랜잭션 프록시

OrderService에서 기술 관련 코드 제거

데이터 기술이 변경되어도 기존 코드는 영향을 받지 않음
TransactionTemplate, PlatformTransactionManager와 같은 기술과 연관된 코드가 계속 등장
트랜잭션의 시작과 종료는 보통 애플리케이션 서비스 메서드 실행 전후

트랜잭션 테스트

트랜잭션이 필요한 곳에 정확하게 적용되었는지 테스트 하기 매우 어려움
JDBC처럼 자동 커밋이 되거나 Spring Data JPA처럼 기본 레포지토리 구현에서 트랜잭션을 알아서 적용해주는 기술을 사용할 때, 트랜잭션이 바르게 적용되지 않은 것을 놓치기 쉬움
모든 작업이 성공하면 하나의 트랜잭션으로 진행된 것인지 여러개의 트랜잭션으로 쪼개진 것인지 확인하기 어려움
트랜잭션 중간에 실패하는 케이스를 만들 수 있다면 롤백 여부로 확인할 수 있음
트랜잭션을 담당하는 클래스나 인터페이스가 등장할 수 밖에 없는가?

트랜잭션 프록시

데코레이터 패턴

오브젝트의 코드를 변경하지 않고 새로운 기능을 런타임에 부여하는 디자인 패턴

프록시 패턴

타깃을 대신해서 존재하며 접근을 제거하거나 보안, 지원, 원격 접속 등의 기능을 제공
타깃을 가지고 있어야 함

데코레이터와 프록시는 유사함

데코레이터는 기능 부여
프록시는 접근 제어

트랜잭션 프록시

OrderSerivice 인터페이스 추출
트랜잭션 부가 기능을 제공하는 OrderServiceTxProxy 프록시

트랜잭션 프록시 적용

동일한 OrderService 인터페이스를 구현한 프록시를 OrderClient에 주입
OrderServiceTxProxy를 거쳐서 OrderService에 감

예시 코드

package tobyspring.hellospring.order;

import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.support.TransactionTemplate;

import java.math.BigDecimal;
import java.util.List;

public class OrderServiceTxProxy implements OrderService {

    private final OrderService target;
    private final PlatformTransactionManager transactionManager;

    public OrderServiceTxProxy(OrderService target, PlatformTransactionManager transactionManager) {
        this.target = target;
        this.transactionManager = transactionManager;
    }

    @Override
    public Order createOrder(String no, BigDecimal total) {
        return new TransactionTemplate(transactionManager).execute(status ->
                target.createOrder(no, total)
        );
    }

    @Override
    public List<Order> createOrders(List<OrderReq> reqs) {
        return new TransactionTemplate(transactionManager).execute(status ->
            target.createOrders(reqs)
        );
    }
}

스프링이 만들어주는 트랜잭션 프록시

@Transaction 애노테이션이 붙은 클래스의 메소드가 트랜잭션 안에서 실행되도록 프록시를 만들어 줌

스프링의 프록시 AOP

AOP는 스프링에서 그다지 성공하지 못한 핵심 기술 중의 하나
활용 용도가 제한적이면서 막상 사용하기는 매우 어려움
스프링이 만들어 놓은 트랜잭션과 보안 기술에서는 유용하게 활용
직접 활용하려면 꽤 많은 학습이 필요함
AOP는 아니더라도 데코레이터/프록시 패턴의 동작 원리를 이해하고 필요한 곳에 활용할 수 있음

all-cloudz commented 1 month ago

Spring에서 서비스는 뭐야?
- Layered Architecture
  - Presentation Layer → @Controller
  - Business(Service, Application) Layer → @Service
  - Persistence(Data Access, Infrastructure) Layer → @Repository
- 서비스의 정의
  - 클라이언트가 원하는 것을 제공하는 오브젝트나 모듈
  - 상태를 가지지 않음 → 싱글톤 빈에 적합
- 서비스의 종류
  - 애플리케이션 서비스 (Application Service) : 애플리케이션 계층에 존재하는 서비스, @Service를 적용
  - 도메인 서비스 (Domain Service) : 엔티티와 같은 도메인에 비즈니스 로직에 추가, 도메인 모델 패턴
  - 인프라 서비스 (Infrastructure Service) : 비즈니스 로직(메일, 캐시, 트랜잭션, 메시징 등)에 필요한 기술을 제공하는 서비스, 서비스 추상화의 대상!!
- 스프링이 제공하는 서비스는 인프라 서비스를 의미함
JPA라는 기술에 의존하는 코드를 분리해볼까
- @Entity, @Table 등 JPA를 위해 사용하는 애노테이션 제거
  - 애노테이션 를 생각해보면 컴파일 시점에만 JPA 라이브러리에 의존하며, 클래스 코드에는 JPA 기술과 관련된 내용이 들어가지 않음 ⇒ @Entity는 JPA를 사용하지 않으면 아무런 동작도 하지 않음 ⇒ @Entity가 JPA에 의존한다고 보지 않을 수 있음, 다른 데이터 기술에서 사용해도 괜찮음
  - 그럼에도 @Entity를 사용하지 않고 싶다면, META-INF 하위에 XML 파일로 엔티티의 메타 정보를 추가하면 되기는 함
- Service가 의존하는 클래스에서 JPA 기술이 드러나지 않게 리팩토링
  - Repository에 의존 역전 원칙(DIP) 적용 ⇒ Repository 인터페이스 도입
  - JpaTransactionManager는 어떻게 제거할까? ⇒ Spring이 PlatformTransactionManager로 트랜잭션 (인프라) 서비스를 추상화를 해두었음
서비스 추상화는 뭐지?
- 다양한 인프라 서비스를 선택(변경)할 수 있는 경우에는 의존 역전 원칙을 지키기 위한 징검다리가 필요함
  - 특정한 인프라 서비스의 특수한 메서드에 의존하면 인프라 서비스를 변경할 때 사용하는 부분을 모두 고쳐야하는 어려움이 있음
- 스프링이 인터페이스만 제공했다면 다양한 인프라 서비스 제공자가 매우 불편할 수 있음 ⇒ 스프링이 핵심 로직만 추가적으로 미리 구현한 어댑터를 제공하면 되지 않을까?
  - 트랜잭션 인프라 서비스의 경우에 인터페이스는 PlatformTransactionManager이고, 해당 인터페이스를 구현한 어댑터는 JpaTransactionManager, JdbcTransactionManager 등이 있음
- 다양한 구현체의 공통 기능을 추출하여 인터페이스와 어댑터를 스프링이 만들어주었기 때문에 구현체에 의존하지 않는 코드를 편하게 작성할 수 있음
트랜잭션 테스트
- 트랜잭션이 적용되었는지를 테스트하려면 에러를 일으키고 확인해야 함
  - 잘못 구현된 경우에는 하나의 트랜잭션으로 관리되어야 하는데 여러 트랜잭션으로 쪼개진 것일 수도 있음
  - 하나의 트랜잭션 내에서 실행하는 각 비즈니스 로직이 실패하는 테스트 코드를 작성할 수 있을까? ⇒ 일반적으로 쉽지는 않음
다시 돌아온 데코레이터 패턴과 프록시 패턴 ⇒ 트랜잭션 로직을 코드에서 분리하기
- Decorator나 Proxy를 연결하여 붙이는 것이 가능 (Composite Pattern, Chain Pattern)
- 트랜잭션 로직을 프록시로 넘기고, 비즈니스 로직을 수행하는 타겟을 프록시에서 호출 (메서드 주입)
AOP와 프록시
- AOP는 어떻게 프록시를 생성하는가?

all-cloudz commented 1 month ago

데코레이터 패턴과 프록시 패턴의 차이는?

프록시 패턴과 구현 방법이 같음
- 다만 프록시 패턴은 클라이언트가 최종적으로 돌려받는 반환값을 조작하지 않고 그대로 전달
- 데코레이터 패턴은 클라이언트가 받는 반환값에 장식을 덧입힘

all-cloudz commented 1 month ago

추가 정리할 것

[ ] 추상화는 무엇이지?
- 섹션5, 6에서 스프링에서 추상화를 어떻게 적용해왔는지 봐왔음
- 그래서 프로그래밍(또는 OOP)에서 추상화라는건 뭐라고 정의할 수 있을까?
[ ] JdbcClient, RestClient의 사용법, 템플릿 콜백 패턴 등이 적용된 사례 등을 정리
[ ] 트랜잭션 롤백 테스트의 베스트 프랙티스는?
[ ] Builder 패턴 구현해보기
[ ] Spring은 AOP를 어떻게 구현했는가?

Leehyoungwoo / spring-study

토비의 스프링 6 | 섹션 6 요약 #6

서비스 추상화 (Service Abstraction)

서비스 - @Service

스프링에 대한 오해

스프링 애플리케이션 빈이 존재하는 계층 구조

서비스의 종류

애플리케이션 서비스 도입 - @Service

기술에 독립적인 애플리케이션 서비스

OrderService

Order

Order에서 JPA 메타데이터 분리

/META-INF/orm.xml

특정 기술(JPA)에 의존하지 않는 애플리케이션 서비스 만들기

트랜잭션 서비스 추상화 - PlatforeTransactionManager

Transaction은 데이터 기술에 따라 방법이 다르다

추상화

개별 트랜잭션 기술의 디테일에 의존하는 클라이언트

JDBC 데이터 엑세스 기술 - JdbcAsync/DataSourceTransactionManager

JdbcClient

DataSourceTransactionManager

트랜잭션 프록시

OrderService에서 기술 관련 코드 제거

트랜잭션 테스트

트랜잭션 프록시

데코레이터 패턴

프록시 패턴

트랜잭션 프록시

트랜잭션 프록시 적용

스프링이 만들어주는 트랜잭션 프록시

스프링의 프록시 AOP