참고자료:
아키텍쳐(Architecture)란 ?
시스템 목적을 달성하기위해 시스템의 상호작용등의 시스템디자인에 대한 제약 및 설계이다 시스템의 구조, 행위, 더 많은 뷰를 정의하는 개념적 모형으로, 시스템 목적을 달성하기 위해 시스템의 각 컴포넌트가 무엇이며 어떻게 상호작용하는지, 정보가 어떻게 교환되는지를 설명한다.
-wiki 아키텍쳐란-
- 즉, 어떤 시스템을 만들기 위한 전체적인 흐름의 디자인이라고 생각한다.
- 개념적으로 시스템의 구성물들이 각각 어떤 역할 수행할지 정의함으로써 세분화 및 구조화를 목적을 이룬다.
이것을 공부한 이유 ...
- 이번에 flask를 시작하면서 가장 처음에 당황스러웠던 점은 무언가 없어도 너무 없다는 것이다. 공식문서에서는 라우팅,비즈니스 로직, db 로직, 앱 환경설정 등... 하나의 파일에서 뭔가 다 될거같은 느낌이였다. 하지만, 프로젝트를 다른 사람들과 진행해야되는데, 하나의 파일에 그렇게 모든 로직을 다 때려박으면 나중에 github이나 rebase할 때 엄청난 conflict이 일어날거 같아서 여러가지를 찾아보던 중 이 아키텍쳐에 대해 공부하게 되었다.
계층화 아키텍쳐란?
General Information
- 아키텍쳐의 컴포넌트들은 각각 어플리케이션의 특정한 역할을 수행하도록 가로로 나누어져 계층을 이룬다.
- 가장 널리 알려진 아키텍쳐로 전통적인 IT workflow 와 조직 구성과 잘 맞아 떨어져서 많은 비즈니스에서 채택된다.
- 주로 3가지 계층으로 이루어져 있다.
- 유저 + 브라우저와 상호작용하는 로직이 잇는 Presentation Layer
- 요청에 맞는 비즈니스 로직을 수행하는 Business Layer
- 데이터를 저장하고 관리하는 persistence Layer가 있다.
- 각각의 계층은 다른 계층과 상호작용하지만, 다른 계층에서 발생하는 로직에는 신경쓰지 않아도 된다. 예를 들어, 데이터를 다루는 persistence layer는 그 데이터가 보여지는 presentation layer를 신경쓰지 않아도 되며, 오로지 자신의 역할에만 집중하면 된다.
클라이언트의 요청에 따른 흐름도
주의점
- 위의 그림에서 나오듯이 많은 계층을 통과하기 때문에 Performance에서 안좋을수 있다.
- 한번 적용되면 다른 패턴을 섞는다거나 조금 수정하는 유연함은 조금 떨어진다.
- 어플리케이션의 서비스가 커짐에 따라 유지하기 힘든 구조이다.
- 하지만, 각 계층의 역할이 명확하여 개발과 테스트가 편해진다.
Flask에서 적용
- 위와 같은 개념을 인지하니깐 그나마 프로젝트 파일들을 어떻게 관리해야되는지 감이 좀 왔다. 나는 위와 같은 패턴으로 다이렉토리를 다음과 같이 구분하였다.
0. migration파일 + docker + git + manage.py가 오게될 최상위 프로젝트 폴더
1. app에 대한 설정을 하는 app 폴더
2. 어플리케이션의 설정 + DB 관리 파일 + 어플리케이션의 각 계층에 해당하는 폴더가 있는 main 폴더
3. url 호출시 처음 요청을 분석하는 urls 폴더
4. 요청에 부합하는 로직을 다루는 views 폴더
5. 마지막으로 orm으로 DB 데이터를 관리 및 저장을 담당할 models 폴더
특이사항
- 소캣 통신시 발생하는 event는 따로 파일을 분리할지 views 폴더에 집어넣을지 아직 고민중... (event-driven architecture)
- DJANGO랑 많이 비슷하게 만들었지만 파일 구조가 많이 다른 것을 확인 ... 하지만 비슷한 방식으로 어플리케이션을 구현할 수 있으니 path만 잘 다룰 수 있다면 문제 없다고 판단
- SQL Alchemy + Flask-Migrate로 DJANGO와 비슷한 ORM 환경구축
- Flask-Restful 라이브러리 적용할려다가 그다지 필요없을거같아서 적용 X
- Flask-Script로 manage.py를 django에서의 manage.py로 구성
- 그 외에 뭐 flaks-mysql 인지 socketio인지 cors 다루는 것도 설치
# 개발 # 컴퓨터공학