소프트웨어 디자인 패턴(software design pattern)은 소프트웨어 공학의 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계 코드로 바로 전환될수 있는 완성된 디자인은 아니며, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿이다. 디자인 패턴은 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 관행이다.
레이어드 아키텍처 패턴
Presentation 계층
사용자와 상호 작용 처리 계층
CLI, HTTP 요청, HTML 처리 등을 담당한다.
HTTP 요청 처리 및 HTML 렌더링에 대해 알고 있는 웹 계층
흔히 말하는 MVC (Model / View / Controller) 도 이 계층에 속한다.
우리가 URL을 매핑해서 특정 메서드가 해당 URL로 요청이 올 때마다 호출되게 프로그래밍 했었죠?
그 계층을 말하는 것이며, 스프링에서는 @Controller 어노테이션을 사용하여 표현합니다!
Domain(Business or Service) 계층
서비스/시스템의 핵심 로직
유효성 검사 및 계산을 포함하는 Business 논리 계층
애플리케이션이 수행해야하는 도메인과 관련된 작업들을 담당한다.
입력/저장된 데이터를 기반으로 계산
Presentation 계층에서 받은 데이터의 유효성 (Validation) 검사
어떤 Data Access 를 선택할지 결정
우리의 서버 프로그램이 복잡해지면, 비즈니스 로직을 수행하기 위한 별도의 계층(Layer)이 필요합니다.
사실 더 이상적으로는 유능한 서버 프레임워크를 써서 Presentaion, Data Access계층에는 별로 할 일이 없고,
도메인 계층이 비대해지는게 가장 좋습니다.
스프링에서는 @Service 어노테이션을 사용해서 표현합니다!
Data Access(Persistence) 계층
DAO 계층
Database / Message Queue / 외부 API와의 통신 등 처리
데이터베이스 또는 원격 서비스에서 영구 데이터를 관리하는 방법을 분류하는 데이터 접근 계층
우리의 데이터베이스, 혹은 데이터를 저장하는 데이터 소스는 서버 외부에 별개로 존재하는 경우가 매우 많고, 그러한 데이터 소스와의 소통을 해주는 계층이라고 생각하시면 될 것 같습니다.
스프링에서는 @Repository 어노테이션을 사용해서 표현합니다.
스프링/스프링부트를 사용하는 이유?
단순 반복작업부분이 많았던 Controller와 Repository쪽을 개발 관점에서 매우 쉽고 편하게 처리해줘 가장 중요한 핵심 비즈니스 로직인 Service 레이어에 더 집중 할 수 있도록 하게 해준다는 이유를 꼽기도 합니다.
