기존 MVC 패턴의 문제
이번 프로젝트에는 MVC 패턴을 적용해 구현하고 있었다. 그런데 어느 정도 구현을 다 하고 보니 컨트롤러에 너무 많이 역할이 부여되고, 레이어별 역할 구분이 명확하지 않은 느낌이었다. 그래서 중간에 하나의 레이어를 두어 일부 역할을 분리해도 좋지 않을까 생각했다.
문제 해결의 실마리
그러다 이러한 고민에 어느 정도 실마리가 되어 준 것이 바로 레이어드 아키텍처(Layered Architecture)라는 것이었다. (참고: Layered Architecture @hgraca)
Layered Architecture @herbertograca
말이 거창해 보이지만, 쉽게 말하자면 각 계층을 애플리케이션 내에서의 특정 역할과 관심사(UI, 비즈니스 로직 수행, DB 작업 등) 별로 구분한다는 것이다. 가장 큰 특징은 명확하게 관심사를 분리할 수 있다는 장점이 있다는 것이다.
즉, 특정 계층의 구성 요소는 해당 계층에 관련된 기능만 수행하기에 높은 유지보수성과 쉬운 테스트를 할 수 있다는 장점이 있다. (참고: 계층화 아키텍처) 그래서 이 아키텍처라면 각 레이어별로 역할과 책임이 명확해, 컨트롤러의 역할이 너무 많은 것 같다는 고민을 해결할 수 있을 것 같았다.
문제 해결의 방향성
그렇다면 어떻게 해결했느냐? 아래와 같이 컨트롤러 전에 비즈니스 로직을 수행하는 '서비스 모듈'을 하나 더 두기로 했다.
컨트롤러 모듈controller.js → 컨트롤러 역할
서비스 모듈___Service.js → 비즈니스 로직 (이런저런 계산 등) 수행
___Validator1.js → 유효성 검사 1
___Validator2.js → 유효성 검사 2
___Validator3.js → 유효성 검사 3
___Validator4.js → 유효성 검사 4
서비스 레이어
서비스 레이어는 비즈니스 로직을 수행하는 것을 주 관심사로 두고 그저 Model에서 데이터를 가져와(로또 번호, 구입 금액 등), 비즈니스 로직(당첨 통계와 수익률 계산 등)을 수행한다. View가 화면에 데이터를 출력하거나, Controller가 View에서 가져온 결과물을 원하는 형식으로 다듬는지에 대한 내용은 알고 있지 않다.
확정된 구조
아키텍쳐의 본질
사실 내가 적용한 Layered Architecture 외에도 어니언 아키텍처(Onion Architecture), 라자냐 아키텍처(Lasagna Architecture) 등등 여러 아키텍처가 있었다.
출처: Javi's Dev Blog
하지만 이번 프로젝트에서는 어떤 아키텍처를 사용하냐는 것은 본질이 아니었다. 기존 MVC 패턴을 사용하며 컨트롤러가 가지고 있던 필요 이상의 역할을 여러 레이어로 나누고, 각 레이어별로 관심사와 역할을 분리하는 것이었다.
레이어드 아키텍쳐 도입의 효과
이 아키텍처를 참고하며 결과적으로는 비즈니스 로직을 가장 바깥쪽에 두지 않으면서 핵심적인 비즈니스 로직은 견고하게 유지할 수 있었다. 예를 들어 보너스 번호의 개수가 1개에서 2개로 변경되어야 한다면 굳이 사용자 입출력을 변환하는 컨트롤러는 건드릴 필요가 없다. 서비스 레이어의 내부 로직만 변경하면 된다. 이에 더해, 역할 분리가 되니 각각의 유닛테스트를 짜기가 수월하기도 했다.
사실 짧은 시간 동안 아키텍처에 대해 깊게 공부하거나 적용하는 것은 무리가 있다고 생각한다. 평소에는 이런 구조적인 고민을 할 일이 없었는데, 덕분에 이런 아키텍처라는 것까지 찾아보고 고민해 본 것에 의의를 둔다.