6장 - 영속성 어댑터 구현하기

애플리케이션 서비스에서는 영속성 기능을 사용하기 위해 포트 인터페이스를 호출합니다.

이 포트는 실제로 영속성 작업을 수행하고 데이터베이스와 통신할 책임을 가진 영속성 클래스에 의해 구현됩니다.

영속성 어댑터는 주도되는 어댑터이며 애플리케이션에 의해 호출될 뿐, 애플리케이션을 호출하지 않습니다.

 

영속성 어댑터의 책임

- 입력을 받는다

- 입력을 데이터베이스 포맷으로 매핑한다

- 입력을 데이터베이스로 보낸다

- 데이터베이스 출력을 애플리케이션 포맷으로 매핑한다

- 출력을 반환한다

 

포트 인터페이스 분리하기

ISP에 의거하여 하나의 비대한 포트를 갖는 것보다 서비스가 실제로 필요한 메서드만 사용하는 것이 좋습니다.

 

영속성 어댑터 분리하기

영속성 어댑터 클래스도 기능에 따라 경계를 나눌 수 있습니다.

 

스프링 데이터 JPA 예제

Account 도메인 모델과 AccountJpaEntity 모델 간 양방향 매핑이 존재합니다.

그냥 JPA 애너테이션을 Account 클래스로 옮기고 이걸 그대로 데이터베이스 엔티티로 저장하면 안 될까요?

'매핑하지 않기'전략도 유효할 수 있습니다.

 

하지만 영속성 측면과 타협 없이 풍부한 도메인 모델을 생성하고 싶다면 도메인 모델과 영속성 모델을 매핑하는 것이 좋습니다.

 

데이터베이스 트랜잭션은 어떻게 해야 할까?

트랜잭션 경계는 어디에 위치해야 할까요?

특정한 유스케이스에 대하여 일어나는 모든 쓰기 작업에 걸쳐 있어야 합니다.

 

스프링에서는 @Transactional 애너테이션을 애플리케이션 서비스에 붙여서 실패할 경우 다 같이 롤백될 수 있습니다.

 

유지보수 가능한 소프트웨어를 만드는데 어떻게 도움이 될까?

도메인 코드가 영속성과 관련된 것들로부터 분리되어 풍부한 도메인 모델을 만들 수 있습니다.

포트마다 다른 방식으로 구현할 수 있는 유연함이 생깁니다.

심지어 포트 뒤에서 애플리케이션이 모르게 다른 영속성 기술을 사용할 수도 있습니다.