MVC 패턴을 사용하여 개발하다 보면 비즈니스 로직을 담고 있는 파일들이 점점 커지는 것을 느낄 것이다.
서비스가 커질수록 비즈니스 로직이 복잡해지기 시작했고 유지보수가 점점 힘들어진다고 느꼈다.
문제점
"Controller는 최대한 가볍게"라는 원칙에 따라 개발했다면 Model에서 비즈니스 로직을 작성하는 경우가 심심치 않게 생길 것이다. 이를 좀 더 보완하기 위해 Service계층을 따로 작성하여 Model에 작성한 비지니스 로직을 Service에서 작성하기 시작했다. 하지만 하나의 계층이 나뉘었을 뿐 여전히 비즈니스 로직에 대한 유지보수는 쉽지 않았다.
비즈니스 로직이 복잡해질수록 오류가 났을 때 오류를 해결하기 위해서 내가 작성한 비즈니스 로직에서 문제점을 계속 찾아야 했고 이로 인해서 유지보수가 점점 복잡해지기 시작했다고 느꼈다. 이를 해결하기 위해 계층을 좀 더 세분화 시킬 필요가 있었다.
전략
각각의 계층을 나누고 각 계층에서는 주어진 역할만 수행할 수 있게끔 로직을 작성하여 유지보수의 효율성을 높인다.
Model : 데이터 베이스와의 연결 계층으로 사용한다.
Controller : Model과 View를 연결하는 계층으로 사용한다.
Service : 비즈니스 로직을 작성하는 계층으로 사용한다.
Repository : 비즈니스 로직에 필요한 쿼리를 작성하는 계층으로 사용한다.
Interface : 사용할 함수를 정의해 놓는 계층으로 사용한다.
장점
- 비지니스 로직과 DB 접근 로직 간의 결합 도가 낮아진다.
- 각 계층 간의 수정이 가능해진다.
- 결합 도가 낮아져서 테스트 코드를 작성하기 유리해진다.
- 추상화 적 요소를 가지고 있어서 객체의 공통적인 속성과 기능을 정의하는 것이 가능해진다.
단점
- 모든 객체지향의 단점이겠지만 개발 속도가 느리다.
- 관리해야 할 파일이 많아진다.
마치며
다음 포스팅에서는 실제로 해당 계층들이 어떻게 사용되는지를 알아보자.
실습에선 Laravel을 사용할 예정이다.
