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