프론트엔드 아키텍처 & 디자인

프론트엔드 아키텍처 & 디자인

잠시 쉬어가며 기초를 다시 한번 정리하면 좋겠다고 생각하는 도중, 초반 프로젝트 구조 잡기에 대해 생각을 했었습니다.
예전, 프로젝트를 개발할 때 뭔가 있어보이는 아토믹 디자인 패턴, Presentational and Container Component 패턴등을 그냥 선택하여 사용하였습니다. 초반에 아키텍처 & 디자인 패턴의 중요성을 모르고 확실히 정하지 않아 개발을 하여 여러번의 회의, 개개인이 이해한 패턴대로 프로젝트를 진행하고 있었습니다. 그래서 코드를 다시 고치려고 할 때 엉망이었습니다. (프로젝트 할 때마다 조금씩 나아지기는 했지만...)

정리 시작합니다.!!

👣 설명

우선, 아키텍처와 디자인의 차이부터 확실히 하고 갑시다.
아키텍처와 디자인은 구조를 만드는 데 필요한 방법론 입니다.

아키텍처 ≒ 디자인 이며 아키텍처 > 디자인 으로 표현을 할 수 있습니다.

아키텍처(Architecture)

소프트웨어 시스템의 기본 구조 (구성과 동작 원리)
ex) 성능, 확장성, 유지 보수성, 테스트, 기술 스택 등 문제 해결

디자인(Design)

소프트웨어 구성에서 반복되는 문제 해결을 위한 구조
ex) 프로그래밍 언어 수준의 문제 해결, 설계 패턴

프론트엔드 입장에서 보면 전체 구조를 MV*와 같은 아키텍처로 구성하고 내부 코드를 아토믹 디자인과 같은 것으로 통일화 시킨다고 생각하면 됩니다.

추가로 구조를 짤때 필요한 비지니스/도메인 로직, 뷰 로직도 알아봅시다.

소프트웨어에서 비지니스/도메인 로직은 '현실 세계의 비지니스 규칙을 프로그램(코드)으로 표현한 것' 즉, 문제를 처리하는 순서라고 할 수 있습니다.

비지니스 로직(Business Logic)

데이터처리를 수행하는 순서
ex) 회원가입 -> data 전송 -> 회원가입 완료

뷰 로직은 보여지는 것입니다. 즉, 사용자로부터 전달 받은 이벤트를 통해 UI(ex. HTML등)을 업데이트 하는 부분

뷰 로직(View Logic)

UI를 처리하는 순서
ex) 삭제 버튼 -> UI 없애기

👣 예시

이젠, 좀 구체적으로 제가 사용했었던 아키텍처와 디자인 패턴을 본래 있던 패턴에 끼워 맞춰가며 설명하겠습니다. 간략하게 패턴이라고 이름을 붙여 설명을 하도록 하겠습니다.

전에 Atomic 디자인 패턴을 사용하였지만 Atoms - Molecules - Organisms - Templates - Pages로 구성되어 있어 단계가 너무 많아 구분하는데 어려움을 겪어 단계가 좀 더 간략한 Dan님의 Presentational and Container Components와 단방향으로 처리하는 Flux 패턴(Redux 사용)를 사용하였습니다.

Presentational and Container Components

Presentational Components(화면 표현하는 부분와 Container Components(데이터 다루는 부분)으로 나눠서 개발하는 패턴

Presentational and Container Components 패턴과 유사하게 사용하였습니다.

• 화면(Page)를 Container로 구성
• Container = 비지니스 로직 + Component
• Component: Data가 붙지 않은 UI 컴포넌트
• Props Drilling부분은 Container에서 Redux 함수 사용하여 해결

Flux

단방향 데이터 흐름

거대한 어플리케이션일 경우 양방향으로 Model과 View를 서로 조작하다보면 계속 얽히고 얽혀 Model간에 의존성이 커져 다른 Model까지 Update해야 하는 경우가 있습니다. 그래서 생겨난 것이 Flux 구조 입니다.
Redux도 Flux와 유사하게 사용하므로 Flux 패턴을 사용한다고 생각했습니다.

Flux 구조

Action -> Dispatcher -> Store -> View -> Action

Action: 어떤한 행위, 그 행위로 부터 넘겨받은 값들을 가진 하나의 객체
Dispatcher: 모든 Action을 받아 Store에 넘겨준다.(데이터 흐름을 관리)
Store: Action을 받아 자신에게 적합한 Action인지 필터링 -> 상태값을 변경하여 View에게 전달
View: 변화된 상태를 받고 다시 렌더링

Redux 구조

Store(데이터 묶음, State) -> Action -> Dispatch -> (middleware) -> Reducer -> Store

Action: State를 어떻게 바꿀지에 대한 행동을 적어놓은 객체
Dispatch: Action을 실행(Action 기록이 남겨진다.)
Reducer: 상태를 변화시키는 로직을 정의한 함수, 새로운 객체를 만들어 낸다.
Store: 상태를 관한 데이터들이 담겨있는 저장소, Reducer에서 새롭게 만든 객체를 덮어 씌운다.
Middleware: Action 객체가 Reducer에서 처리되기 전 원하는 작업 수행 가능한 곳(Action Controll, 비동기 처리때 사용)

상태 관리를 Redux와 내부에서 관리하여 사용하여 Flux패턴을 같이 적용하였습니다.

👣 마무리

제가 사용했었던 패턴은 최근 형태와 맞지 않아 Dan님이 후회한다고 합니다. 패턴에 대해 공부를 하면서 구조에 대해 많은 것을 익혔지만 패턴은 계속적으로 변경될 수 있고 달라질 수 있으므로 맹목적으로 따르지 않고 유연하게 개발하는 쪽으로 나아가야 겠습니다.
긴 글 읽어주셔서 감사합니다.!!!

👣 REF

https://velog.io/@alskt0419/FLUX-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90%EB%9E%80
https://tecoble.techcourse.co.kr/post/2021-04-26-presentational-and-container/
https://ui.toast.com/weekly-pick/ko_20200213
https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
https://velog.io/@teo/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%EC%97%90%EC%84%9C-MV-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94
https://medium.com/@shinbaek89/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-business-logic%EC%9D%98-%EB%B6%84%EB%A6%AC-adc10ae881ab
https://velog.io/@teo/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%EC%97%90%EC%84%9C-MV-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94
https://stackoverflow.com/questions/4243187/whats-the-difference-between-design-patterns-and-architectural-patterns
https://medium.com/ruang-aldo/design-pattern-vs-architecture-pattern-b5cd3ebdea8e
https://velog.io/@eddy_song/domain-logic