레이어드 아키텍처의 문제점을 의존성 역전으로 해결하자

양말·2024년 6월 20일

Spring testcode 디프만 스터디 인프런

SpringTestCode

목록 보기

6/10

해당 포스트는 인프런의 Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트 강의의 도움을 받았습니다

기존 레이어드 아키텍처의 문제점

주문 시스템을 만들어야 한다면 무엇부터 시작할 것 같나요?

JPA Entity 먼저 떠올리셨다면, 계층형 아키텍처를 사용하고 있는 것이며 이는 데이터베이스 주도 설계로 이어지게 됩니다.

위와 같은 계층형 아키텍처에는 문제점이 있습니다.

데이터베이스의 변화에 유연하게 대응하지 못합니다.
Service가 JPA를 직접 사용하고 있기 때문에 Mongo DB와 같은 Document DB로 변경이 어렵습니다.
서비스가 사실상 모든 일을 전부 처리하는 신과 같은 존재가 되어 버립니다.
서비스가 가지고 있는 책임이 커집니다.
도메인의 존재가 숨겨져 명시적이지 않습니다.
동시 작업이 불가능합니다.
규모가 커질수록 확장성이 떨어집니다.

절차지향적 사고를 유도하여 낮은 Testability & BAD SOLID로 이어지게 됩니다.

개선된 아키텍처

도메인 살리기

도메인을 살려 줍니다.

도메인 엔티티와 영속성 객체를 구분할 수 있게 됩니다.
Service는 도메인을 Repository에서 가져와 일을 시키는 역할만 하게 됩니다.

도메인은 계층 간 연결된 의존성이 없습니다.
나가는 화살표가 없다고 생각하면 됩니다.
그러니 계층 간 의존성을 Mocking할 필요도 없습니다.

객체 생성이 쉽고, Testability가 높습니다.

레포지토리 의존성 역전

Service가 Domain, JPARepository 둘에 의존하고 있으므로 의존성 역전을 활용하여 의존성을 약화시켜 봅시다.

JPARepository는 우리가 이미 사용하고 있던 인터페이스입니다.

public interface PostRepository extends JpaRepository<PostEntity, Long> {
	@Modifying
    @Transactional
    @Query("DELETE FROM post p WHERE p.id IN :ids")
    void deleteByIdIn(List<Long> p.deleteFlag = "fasle")

이렇게 구성하게 되면, Test 시에는 다음과 같이 Fake를 활용할 수 있습니다.
h2가 필요 없는 소형 테스트를 만들 수 있는 것입니다!

Repository 인터페이스를 만들어 줍니다.

interface PostRepository {
	Post getById(long id);
    Optional<Post> findById(long id);
    List<Post> findAll();
    void deleteByIdIn(List<long> ids);
}

RepositoryImpl을 만들어 줍니다.

public PostRepositoryImpl implements PostRepository {

	private final PostJpaRepository postJpaRepository;
    
	@Override
	Post getById(long id) {...}
    
    @Override
    Optional<Post> findById(long id){...}
    
    @Override
    List<Post> findAll(){...}
    
    @Override
    void deleteByIdIn(List<long> ids){...}
}