- 요즘 새롭게 알게된 Layered Architecture에 대해 블로깅해보기로 한다.
-
레이어 아키텍처(Layered Architecture)
유사한 관심사들을 레이어로 나눠서 수직적으로 배열하는 아키텍처. -
관심사의 분리(Separation Of Concerns)
아이텍처를 결정할 때 관심사의 이야기를 많이한다. 관심사란 유사한 책임을 의미.
- 마치 케익과 같음. 유사한 관심사들이 층별로 나눠줘 있고 필요한 경우 한 층을 다른 것으로 교체해도 그 구조가 유지됨.
- 하나의 레이어는 자신의 고유 역할을 수행하고, 인접한 다른 레이어에 무언가를 요청하거나 응답하는 형태.
- 그 밖의 다른 레이어는 신경 쓸 필요가 없기 때문에 각 레이어는 자신의 역할에 충실할 수 있다.
- 시스템을 레이어로 나누면 그 중 하나를 다른 것으로 교체하는 것이 가능해진다. 이는 시스템 전체를 수정하지 않고 특정한 레이어의 기능이나 성능을 개선하는 것이 가능함을 의미한다. 재사용과 유지보수에 유리하다.
- 하나의 레이어에서 모든 작업을 전담하게 되면 같은 작업을 반복해서 구현해야 하는 경우가 생기는데, 이로 인해 많은 중복코드가 발생한다.
- 중복 코드를 수정할 때 모든 소스코드를 변경해야 하기 때문에 번거로워진다.
🦖 내가 기본적으로 이해한 것은, ORM을 사용할 때, views.py 에서 모델을 불러오고 데이터를 가져오고 하면서 views.py가 가져야하는 부담감과 그로 인한 중첩, 중복코드들이 비효율적이라는 것들을 알게 됐다. 각 레이어가 자기 역할에만 충실하게 하는 것, 데이터는 데이터 정보만을 갖고 있고, 뷰는 로직만을, 모델은 테이블에 집중하게 하는 것. 그래서 각자 서로의 영역이 필요할 때 요청과 응답을 주고 책임을 분명히 해주는 것. 이것이 레이어드 아키텍쳐의 베이스인 것 같다.
🦖 layaered architecture 기반으로 이번 프로젝트를 하며 확인했던 것은, 각 app들이 views-service-models의 계층을 갖고 있다는 것이었다. 여기에 dto라고 하는 데이터만 담당하는 컴포넌트가 따로 존재한다. service와 dto가 좀 생소하긴해서 이 부분은 좀 더 공부를 해보아야한다.
🦖 views-service-models의 계층에서 각 계층은 다음과 같은 책임을 맡는다.
- views: 전통적인 Layered Architecture의 presentation layer의 역할을 맡아 엔드포인트로 들어온 요청을 정제하여 알맞은 서비스에 전달.
- service: view layer로부터 전달받은 요청을 처리하는 비즈니스 로직을 포함.
- models: 비즈니스 로직 연산을 통한 결과물을 데이터 베이스에 반영하기 위한 코드를 포함.
- 아키텍처는 보통 3종류로 분류
- Presentation Layer: 표현 계층, User Interface, View
클라이언트와 직접적으로 맞닿아있는 레이어이다. 가장 쉬운 예제는 사용자 인터페이스이다. 사용자가 직접 보고 요청을 하고 응답을 받기 때문이다.
Back-end관점에서는 어떨까? 백엔드 관점에서는 MVC Pattern에서 Controller에 해당한다. 엄밀하게 말해서 컨트롤러가 ‘표현’하는 계층이 맞나? 라고 한다면 모르겠다. 하지만 적어도 외부와 가장 맞닿아있는 계층이자 백엔드의 관점에서는 클라이언트가 프론트엔드이기 때문에 어느정도 상통하는 이야기라 생각된다.- Business Layer: 비지니스 계층, Service, Domain, Core
이름처럼 비지니스 로직을 처리하는 레이어이다. 또 다른 이름으로는 Service, Domain 등으로 부를 수 있다. 어플리케이션의 핵심적인 기능을 구현하는 레이어로, 어떻게 표현되는지(Presentation), 데이터 베이스와는 어떻게 통신하는지(Persistance)에는 관심이 없어야 한다.- Presistance Layer: 영속성 계층, Repository, DAO
영속성 계층은 DataBase와 직접 통신하는 레이어이다. Repository pattern이나 MVC패턴의 DAO과 동일하다. 기본적으로 가장 원자단위의 일을 처리하며 그 일은 CRUD(Create, Read, Update, Delete)라고도 한다.
🦖 추가: DTO(Data Transfer Object)
- DTO(Data Transfer Object)는 데이터 전송(이동) 객체라는 의미를 가지고 있다. DTO는 주로 비동기 처리를 할 때 사용한다.
- 계층간 데이터 교환을 위한 객체(Java Beans)이다.
- DB의 데이터를 Service나 Controller 등으로 보낼 때 사용하는 객체를 말한다.
- 즉, DB의 데이터가 Presentation Logic Tier로 넘어올때는 DTO로 변환되어 오고가는 것이다.
- 로직을 갖고 있지 않는 순수한 데이터 객체이며, getter/setter 메서드만을 갖는다. 또한 Controller Layer에서 Response DTO 형태로 Client에 전달한다.
개발 기록