해당 글은 개발, 기술관련 아티클이나 블로그 글 혹은 유튜브 영상의 내용을 정리하거나 후기를 적는 글입니다.
리뷰할 글: '강남언니 공식 블로그' 의 '트랜잭션은 도메인 모델이 아니다'
트랜잭션은 도메인 모델이 아니다
IoC를 이용한 데이터 원자성 확보 by 강남언니 블로그
blog.gangnamunni.com
주제와 간단 요약
- 글쓴이의 상황
- 성과형 광고 시스템 도메인
- 실시간으로 많은 노출, 클릭과 그에 따른 과금이 발생함
- db 의 tx 나 낙관적 동시성 처리를 위한 버전 정보를 도메인 모델에 노출이 될것 같음
- 성과형 광고 시스템 도메인
- 문제 상황 발생
- 동시성 문제가 발생하여 여러가지 rdb 수준의 locking 의 필요성이 발생
- pessimistic locking 을 하기 위해서는 도메인 서비스에
@Transactional
어노테이션이 필요해짐 - optimisitc locking 을 하기 위해서는 도메인 객체에 version 이라는 필드가 필요해짐
- pessimistic locking 을 하기 위해서는 도메인 서비스에
- 위의 두가지 선택지를 모두 사용하지 않고싶어짐
- 이유는 도메인 자체가 가져야할 정보들이 아니기 떄문에
- 동시성 문제가 발생하여 여러가지 rdb 수준의 locking 의 필요성이 발생
- 해결법
- 애그리거트를 읽어와 수정하고 저장하는 문제의 코드 흐름 제어권 배치를 변경하기로함
리뷰와 나의 해석
우선 이 글을 읽고 너무나도 반가웠다. 나도 이런 이슈를 동일하게 경험했던 적이 있기 때문이다.
이 문제의 핵심을 이야기해보자면, domain model 과 persistence entity model 을 분리하여 RDB 를 사용할 때 ACID 가 지켜지지 않는 것 이다.
이유인 즉, 영속성 장치가 ACID 를 보장해주는 범위는 영속성 장치가 인정하는 영속 모델의 경우이기 때문이다.
여기서 말하는 영속성 장치가 인정하는 영속 모델이란 @Entity
어노테이션이 붙은 JPA entity 라던지, @Table
어노테이션이 붙은 모델을 의미한다.
이런 경우 비관적/낙관적 잠금이 불가능해지는데, 이를 해결하는 방법으로 글쓴이는 repository 로 도메인 서비스의 로직을 위임시켰다.
도메인 로직을 지키기 위한 고민과 그 고민 사이에 있었던 글쓴이의 통찰력이 묻어나오는 글이었지만 조금 아쉬운점이 있다.
이렇게 된다면 EventHandler 의 도메인 로직이 repository 로 밀어져버리게된다.
그렇다면 JpaRepository
도 DomainRepository
를 Compsite 한 CampaignRepository
가 도메인 로직을 알게되는 것인데, 이는 Spring 에 관련된 객체이기 때문에 이 또한 문제라고 생각한다.
그렇게되면 계속되는 도메인로직에 Repository 만 커져갈 것이다.
어떻게 해결하면 좋을까? 는 글을 쓰는 와중에도 계속 고민이되는 부분이다.
몇가지 드는 생각은, 과연 EventHandler 는 도메인 레이어일까? application layer 이지 않을까?
그냥 version 정보를 도메인 레이어에 침투시켜버리면 안되는걸까? 그리곤 외부에서 사용하지 못하게 접근제어자를 적절하게 사용하면 되지 않을까? (<- 이 방법은 이전에 내가 했던 프로젝트에서 사용하던 방법이다.)
댓글7