우리가 어떤 의도를 갖고 무언가를 만들어낼 때
만드는 과정을 알고 해당 과정이 왜 이뤄져야하는 지 알고 있다면
그것을 만들기 위해 협업할 때 서로가 맡은 일을 이해하기 쉽고 함께 해나가야 할 때 작업능률이 올라가고 일의 강도 또한 수월해진다.
또한 어떤 일에서라도 규격화 / 매뉴얼화된 지침이 있다면 이를 따르는 일원들은 그 지침이 가져다주는 효율에 따라 일의 능률을 올릴 수 있다는 장점이 있다고 본다.
지금 배우는 아키텍처 패턴도 같은 이치라고 생각한다.
아키텍처 패턴
소프트웨어의 구조를 구성하기 위한 가장 기본적인 토대를 제시하는 패턴
장점 : 검증된 구조 / 안정적인 개발 가능성 증가
- MVC (Model View Controller) 패턴
Model : 데이터와 비즈니스 로직 담당
View : UI를 담당
Controller : 클라이언트의 요청을 모델과 뷰로 전달해주는 역할 담당
- 계층형 아키텍처 (Layered Architecture) 패턴
Presentation Layer : 클라이언트 - 서버가 처음 만나는 계층 (메인 파일처럼 url이나 router를 사용해 연결하는 계층) => UI
Application Layer : 프로세스 조정, 데이터 흐름 관리, 비즈니스 로직 계층에 필요한 규칙을 호출하고 조정하는 계층 => Controller
Business Layer : 비즈니스 로직을 처리하는 계층 => Service
Persistence Layer : 영속성 계층 (데이터베이스와 연결되기 위한 계층) => Repository
Database : 데이터베이스
- 클린 아키텍처 (Clean Architecture) 패턴
소프트웨어를 내부로 향하는 의존성을 갖는 여러 계층으로 분리한 패턴
클라 요청 처리, DB 조작, 외부 시스템과의 통신은 외부 계층에서 처리
소프트웨어의 유지보수성과 확장성을 향상시키는 것이 주 목표
- MSA 마이크로 서비스 아키텍처 (Microservices Architecture) 패턴
시스템을 작고 독립적으로 배포 가능한 서비스로 분할하는 패턴
하나의 시스템에서 다양한 언어, 프레임워크를 도입한다.
서비스 간 통신을 API 또는 이벤트 기반 아키텍처(Event Driven Architecture)를 통해 통신한다.
계층형 아키텍처 패턴은?
- 각 계층 간의 연결을 최소화한다.
- 계층 내의 응집은 최대화한다.
클라이언트 - 서버 간 HTTP 통신을 위해 프로젝트 폴더 내 서버 파일을 계층형 아키텍처 패턴으로 구현한다면?
-
컨트롤러
router
-> router를 생성하고 API 통신
controllers
-> router가 API통신을 하기위해 호출하는 함수들을 여기서 구현
-> http 상태코드, 메시지 또는 req, res을 이곳에서 구현한다. -
서비스
services
-> controller에서 구현하는 함수의 세부 기능(비즈니스 로직)을 여기서 구현
-> Repository에게 데이터를 요청하거나 비즈니스 로직 수행 후 사용자에게 보여줄 데이터를 가공하여 반환한다. -
저장소
repositories
-> 데이터베이스 CRUD, 연결, 해제, 자원관리를 담당한다.
-> DB와 연결하여 데이터를 관리하기 위해 해당 DB에 맞는 메서드를 사용한다.
-> CRUD하여 얻은 값을 반환하여 service 계층에서 사용할 수 있도록 한다.
