학습계기
지금까지 당연하게 Controller , Service , Mapper 를 통해서 개발을 진행하였으나, 처음 시작을 이렇게 시작해서 개발하게 된 것이지 이 구성의 정의를 구체적으로 알지는 못하였기 때문에 알아볼 기회를 가져보려 한다.
개발에서 중요한게 뭘까?
내 기준에서는 신선한 코드보다는 유지보수가 좋은 코드가 먼저 생각이 난다. 그리고 확장성과 재사용성이 뛰어난 코드들이 좋은 코드라고 생각 된다.
이에 따른 코드의 구조를 관리할 필요성이 대두 되었고, 다양한 방법들이 있지만 오늘 내가 알아볼 내용은 레이어드 아키텍쳐 패턴이다.
레이어드 아키텍쳐 패턴은 코드를 논리적인 부분 혹은 역할에 따라 독립된 모듈로 나눠서 구성하는 패턴이고 각 모듈이 쌓이면서 붙어있는 모듈들 끼리는 서로 의존하며 연결되어 있다.
해당 시스템을 사용하는 사용자 혹은 클라이언트 시스템과 직접적으로 연결되는 부분
웹사이트의 UI 에 해당하는 부분이며 백엔드 API 에서는 EndPoint 에 해당하는 부분이다.
=> presentation layer 에서는 API의 엔드포인트를 정의하고 전송된 HTTP 요정(request)을 읽어들이는 로직 구현
실제 시스템이 구현해야하는 로직을 Business layer 에서 구현함
백엔드 API에서는 presentation layer 에서 전송된 요청을 읽어들여 요청에 맞게 동작하는 로직을 구현하면 됨
데이터베이스와 관련된 로직을 구현하는 부분.
Business layer에서 필요한 데이터를 생성, 수정, 조회 등을 처리하여 실제 데이터베이스에서 데이터를 저장, 수정, 조회를 하는 역할을 담당
레이어드 아키텍쳐의 핵심요소는 단방향 의존성이다.
레이어의 단계를 뛰어 넘어서 간섭하면 안된다는 것
예를 들어 presentation layer 에서 필요한 것을 Business layer에서 구현해서 사용해야지, persistence layer에서 구현하면 안된다는 것
다른 핵심요소는 각 레이어의 역할이 명확하다는 것이다.
예를 들어서 presentation layer는 화면 (Client)과의 소통을 담당하지 다른 layer 가 간섭하면 안된다는 것이다.
=> 이 두가지를 지킴으로써 각 레이어가 독립적이고 역할이 분명해져 코드의 확장성이 높아질 뿐만 아니라, 재사용 가능성도 높아진다.
자바로 된 애플리케이션의 경우 클래스는 두 종류로 나뉜다.
기능을 맡은 클래스는 3레이어 (presentation, business, persistence) 처럼 로직을 수행하고, 데이터를 담는 클래스는 데이터만 담는다. 기능을 맡은 클래스에게 데이터를 요청했을 때, 데이터를 담는 클래스에 요청을 보내 응답을 받아오게 된다.
그리고 그 결과는 객체 상태로 들어오게 된다. 이런 데이터를 담기 위한 클래스들이 있다.
Controller - DTO
Service - Model
Persistence - Entity
생각
개발을 하다보니 DB에 끌려가는 일이 많았던 것 같았는데, 그 이유중 하나를 알게 된 것 같은 느낌이다.
의존하고 있는 레이어가 아닌 다른 레이어를 끌어서 주입하여 사용하였던 경험들이 있는데 철저히 지양되어야 할 행동임을 자각할 수 있었다.
DTO, Model, Entity 에 대한 추가 학습 필요함
출처 :
https://kimjingo.tistory.com/159
https://cat-minzzi.tistory.com/74
https://6mini.github.io/software%20architecture%20pattern/2022/11/16/layered-architecture/