레이어 아키텍처 구조 개선하기

[문제점 성찰]

현재 나의 프로젝트 구조는 신규 개발자가 대중적으로 사용하는 레이어 아키텍처를 사용 중이었다. 

레이어 아키텍처는 가장 가시적이고 무언가 만들때 쉬운 방법이었다.

하지만 단점이 존재한다. 

첫 째, 모든 것이 영속성 계층을 기준으로 만들어진다. 우리가 개발을 시작하기 전에 가장 먼저 작성하는 것은 테이블 명세, ER 다이어그램이다. 각 엔티티의 관계를 고민하고 어떻게 연결하며, 어느정도 정규화를 통해 만들어낼지 고민하는 과정을 거치게 된다. 도메인을 먼저 고민하기보다 유스케이스를 통해 어떤 행위가 먼저 이뤄질지 고민하는게 맞는 것 같다는 어느 한 강의를 듣게 되었다. 다음 단점을 보며 내용을 이어나가겠다.

둘 째, 계층형 아키텍처는 업무 도메인에 대해 어떠한 정보도 제공해주지 않는다.  실제로 모든 코드가 수동적이고 함수 위주로 돌아간다. 대부분의 중요한 코드는 비즈니스 계층을 통해 수행되며, 객체지향적인 코드가 아닌 절차지향적인 코드를 작성하게 된다. 내가 배운 자바는 객체지향적인 특징이 가장 강한 장점인데 아키텍처에 의해 이 장점이 죽는다면 굳이 자바를 쓸 필요가 없다는 뜻이다.

셋 째, 의존성을 고려하지 않게 된다. 실제로 프로젝트 패키지를 작성하게 되면서 습관적으로 컨트롤러와 서비스, 레포지터리 세가지를 기본으로 만들고 각각의 클래스들을 곧바로 연결하며 작업을 시작했다. 클래스간의 의존성이 얼마나 강하게 묶여있는지 이러한 고민을 해보지 않은체 항상 똑같은 방식으로 작성하게 되는 나쁜 습관이 생겼다.

위 내용에 대한 학습 후 내 프로젝트에는  어떤 개선점이 필요한가 보았더니 아키텍처의 단점을 개선해보려는 의지는 보였으나 왜 그렇게 사용해야하는지도 모른체 인터페이스를 상속받아 남발하고 있었다. 정보처리기사를 공부하며 머릿속에 가장 오래 기억에 남았던 문장은 응집도는 높고 결합도는 낮아야 한다는 점이었다. 하지만 다시 되짚어보니 내 프로젝트는 각각의 레이어가 강하게 결합되어 있었고, 확장에 용이한 구조가 아니었다. 즉 결합도가 높은 단점이 명확하게 드러났다.

 

[개선방법]

우선 왜 인터페이스를 상속받아 사용하는 이유를 다시 되짚어 보기로 했다. 인터페이스를 상속받아 사용하는 이유는 레이어 아키텍처에서 각각의 레이어끼리 강하게 연결된 부분을 느슨하게 하기 위해서이다. 그 패턴을 우리는 어댑터 패턴이라고 부른다. 두 객체 사이에 인터페이스를 두어 강한 의존성을 풀어내는 전략이였다. 

변경된 패키지구조는 아래와 같다. 어댑터 패턴을 적용하여 언제든지 각 인터페이스를 상속받은 상속체를 교체할 수 있는 구조를 만들었다. 만약 RDB가 아닌 NoSQL을 써야한다해도 문제가 없다. Repository인터페이스를 상속받아 동일한 메서드명을 가진 NoSQL 코드를 작성하면 문제가 없다.

이로써, 조금더 유연한 구조를 갖게 되었으며 각각의 레이어에 대한 책임도 더욱 분명해져서 테스트코드를 작성하기에도 조금 더 용이해졌다.

 

[이후 더 개선해 볼 수 있다면?]

흔히 들어본 클린 아키텍처, 헥사고날 아키텍처를 구현해 볼 수 있을것같다.

DB 주도 개발이 아닌 도메일을 중심으로 하는 구조를 갖춰 더욱더 객체지향적인 구조와 코드를 작성할 수 있으며, 도메인 계층을 추가하여 테스트 코드를 작성할 때에도 서로의 클래스에 영향을 받지 않는 유닛 테스트도 가능할 것이다. 자세히 적용해보기 전에 이 과정에 대해서도 학습을 해본 후에 리팩토링을 진행해보려고 한다.