오늘 3번째 TIL을 끄적여 써보려한다.
아직은 코드에 티끌만큼도 모른다고 생각하지만 여러 강의 자료들을 보고,
예제를 풀어보면서 공통적으로 느끼는게 있다.
강의를 하기 위해서는 서로 다른 강사분들이, 자신만의 색깔과 전하고자 하는 메세지를 담아 만든 자신만의 예제와 자료가 있을텐데 푸는 입장에서는 엄청 쉽다고 생각이 들거나 별거 아니라고 생각하고 지나가곤한다.
하지만 막상 나 자신은 그 사소한 클래스 이름, 변수 이름 조차 떠오르지 않아 유용하거나 대표적인 예시를 가져와서 사용을 해왔다.
이렇게 작은 설계와 구상이 어렵다는걸 요새 정말 많이 느끼고 있다...!
코드는 되도록이면 간결하고, 가독성이 뛰어나며 그로인해 유지보수력이 올라가는 형태가 모범적인 형태라고 배웠고.
현재 배우는 입장에서 첫 단추를 그렇게 끼워가며 하려 노력하지만 생각보다 잘안되는게 현실이다....
그래서 오늘은 백엔드에 꽃인 API에서 가장 널리 사용되고 있는 패턴중 하나인 레이어드 아키텍처 패턴(layered architecture) 에 대해서 써보려고 한다.
레이어드 아키텍처 ?
백엔드 API를 구상 및 설계 할때 가장 널리 착안되어 쓰이고 있는 패턴이라고 알면 될것같다.
레이어드 아키텍처의 기본 개념이자 패턴은 API를 구현할때 역할에 따라 독립된 모듈로 나누워서 코드를 구현하는것을 말한다.
각 시스템과 환경에 따라 다를 수 있겠지만, 일반적으로 다음과 같이 3개의 대표적인 레이어가 존재한다.
■ Presentation layer(User Interface) :
해당 시스템을 이용하는 사용자 혹은 클라이언트 시스템과 가장 직접적으로 연결되는 부분이다.
-
CU, HTTP 요청, HTML 처리 등을 담당한다.``
-
HTTP 요청 처리 및 HTML 렌더링에 대해 알고 있는 웹 계층
-
흔히 말하는 MVC(Model / View / Controller) 도 이 계층에 속한다.
■ Business layer(Business Logic) :
실제 시스템이 구현해야하는 로직을 이 레이어에서 구현하게 된다.
-
서비스 / 시스템의 핵심 로직
-
유효성 검사 및 계산을 포함하는 Business 논리 계층
-
애플리케이션이 수행해야 하는 도메인과 관련된 작업들을 담당한다.
-
입력/ 저장된 데이터를 기반으로 계산
-
Presentation 계층에서 받은 데이터의 유효성 (Validation) 검사
-
어떤 Data Access 를 선택할지 결정
■ Persistence layer(Data Access) :
데이터 베이스와 관련된 로직을 구현하는 부분이다.
-
DAO 계층
-
Database / Message Queue / 외부 API와의 통신 등 처리
-
데이터베이스 또는 원격 서비스에서 영구 데이터를 관리하는 방법을 분류하는 데이터 접근 계층
