레이어드 아키텍처의 문제점과 해결방안

2024.11.30 - [Spring/프로젝트 리팩토링 회고록] - 레이어 아키텍처 구조 개선하기

모든 테스트가  h2를 필요로 한다?

• 설계가 잘못되었을 수 있다. 테스트는 외부 객체의 주입을 받지 않은 상태에서도 동작할 수 있는 유닛 테스트가 필요한 경우가 있기 때문이다.
• 또한 작성한 테스트가 실제로 테스트가 필요한 본질적인 책임을 갖고있는 객체가 아닐 수 있다.

 

레이어드 아키텍처의 구조

레이어드 아키텍처는 유사한 기능들을 하나의 계층으로 묶어서 각각의 책임을 지게하는 구조이다.

가장 쉽고 눈으로 봤을때 한 눈에 보인다는 장점이 있어 가장 많이 쓰이기도 한다. 하지만 이 아키텍처는 여러가지 단점이 있다.

아래 이유를 적어놨지만 한 마디로 말해서 절차지향적인 코드를 작성하게된다. 우리는 자바를 객체지향적인 특징이 있어 추상화가 가능하고 유연학 확장을 위해 사용하지만 다 만들고 보면 컨트롤러-서비스-레포지터리 이 순서뿐인 코드를 작성하는 것이다.

첫 째, 데이터 베이스를 주도로 한 설계를 한다는 점이다. 계층형 아키텍처는 대부분 JPA로 엔티티를 만든다고 가정한다면 DB주도 설계로 진행되었을 것이다. 영속성 컨텍스트에 관리를 받아야 하기 때문이다. 하지만 가장  먼저 설계해야 하는 것은 UseCase이다.
예를 들어 강의 서비스를 만든다고 하면 강의 엔티티, 강의실 엔티티등 설계할 엔티티들을 먼저 설계하는 것이 아닌 강의 수강하기, 내 강의 내역 확인, 강의 취소 등의 UseCase가 우선이다. 행동에 대해 도메인을 설계하는 것이 더 효율적이다고 나는 생각한다.(주관적 의견)

둘 째, 동시 작업이 어렵다. 테스트 코드를 작성하기 위해서 Controller의 테스트 코드를 작성한다면 Service가 필요하고 Service는 JpaRepository가 필요할 것이다. 위에서 말했듯이 영속성 컨텍스트 위에 서비스와 컨트롤러가 만들어지기 때문에 Repository계층 없이는 다른 코드들을 테스트 할 수 없다.

셋 째, 객체들을 수동적이고 모든 코드가 함수(메서드)에 의해 작동된다. 의존성에 대해 고민하지 않고 대부분 서비스레이어에서 모든 것이 처리되며 어떤 도메인이 어떤 책임을 맡고 행동하는지 확실하게 보여주지 않는다.

넷 째, 규모가 커질수록 확장성이 떨어진다. 세가지 레이어가 강하게 연결되어 있기 때문에 확장이 필요하게되면 내부 로직을 뜯어 고쳐야하는 문제점이 발생할 수 있다.

 

 

그렇다면 어떻게 개선해야 할까?

레이어에 도메인 계층을 추가해보는 건 어떨까? 도메인을 레포지터리에서 가져와 책임을 위임하는 것이다.

예를 들어 UserEntity를 레포지터리를 통해 가져온다면 그 다음 UserEntity를 User라는 도메인에 책임을 위임하는 것이다.

User라는 객체는 OOP의 특징을 갖는 자바 클래스로 getter,setter같은 보일러플레이트 메서드를 제외한 어노테이션은 없는 오브젝트이다.

이렇게 수행한다면 이 도메인을 가지고 Controller와 Service에서 동시 작업이 가능할 것이다. 왜냐하면 도메인 레이어는 계층간 연결된 의존성이 없기 때문이다.

 

아직 남은 문제점

그림을 보면 알겠지만 아직 Service와 Controller, JpaRepository의 의존성이 강하게 연결되어 있다.

이러한 문제는 낮은 Testability(테스트 가능성)을 발생시킨다.

그럼 어떻게 해결해야 좋을까? 강하게 연결된 두 객체를 느슨하게 연결시켜주는 방법은 스프링의 DI를 공부하며 자주 들어봤을 것이다.

두 객체 사이에 하나의 인터페이스(추상화 객체)를 두는것이다.

두 객체가 하나의 추상화 객체를 바라봄으로써 관계가 느슨해지고 유연한 확장이 가능해진다.

만약 다른 FileComponent나 RedisService등 다른 유틸 컴포넌트가 생긴다면 이 또한 인터페이스를 하나 생성해서 중간에 두고 연결시켜 결합도를 낮추면 된다!