멋쟁이 사자처럼 프론트엔드 심화과정 4기 - Day 6

멋쟁이사자처럼 - 출처 : 나무위키

 

오늘은 처음 들어보는 '클린 아키텍처'라는 개념에 대해서 배웠다.

설명을 듣고 지금까지 프로젝트를 해보면서 진행해보고는 있는데, 사실 아직까지도 개념이 완벽하게 잡히진 않은 것 같다.

그래서 기억을 되짚어 보면서 다시 한번 정리를 하려고 한다.

 

1. 클린아키텍처의 핵심 원칙

가장 중요한 규칙이라고 하면 이걸로 말할 수 있을 것 같다.

 

"안쪽은 바깥을 몰라도 되고, 바깥은 안쪽에 의존해야 한다."

 

이것을 의존성 역전 원칙(Dependecy Rule) 이라고 한다.

 

쉽게 말하면, 화면이 로직을 호출할 수는 있지만 로직이 화면을 호출하면 안된다고 한다.

또한 로직이 데이터를 가져오는 저장소를 호출할 수 있지만, 반대로 저장소가 로직을 호출하면 안된다고 했다.

 

2. 클린 아키텍처의 4계층 구조

클린 아키텍처 - 출처 : http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

 

클린 아키텍처는 4계층으로 나눈다.

 

• Entity (엔티티)
• UseCase (유즈케이스 / 서비스)
• InterFace Adapter (어댑터 / 컨트롤러, DTO 등)
• Framework & Driver (UI, DB 등)

1) Entity (도메인 엔티티)

• 핵심 데이터 구조
• 가장 순수하고, 가장 변하지 않는 영역
• 외부에 절대 의존하지 않음

2) Use Case (비즈니스 로직)

• 데이터로 무슨 작업을 할지 정의함
• 회원 가입하기, 메뉴 좋아요 누르기 같은 '행동'을 정의함
• Repository를 통해 데이터를 가져오지만 어떤 DB인지, 어ㄷ디서 가져오는지는 신경쓰지 않음

3) Interface Adapter (어댑터)

• 데이터를 변환하거나, 외부 요청을 받아주는 곳
• api/menus 같은 API 라우터를 만드는 곳이 여기
• Service와 연결될 수 있게 돕는 브릿지 같은 느낌

4) Framework & Driver

• 진짜 실행되는 곳
• UI, Next.js, Express, MongoDB 등
• 가장 바깥 쪽 계층이고, 이 계층은 언제든 바꿔도 안쪽은 영향받지 않도록 만들어야 함

3. 이렇게 만드는 이유

처음에는 이렇게 나눠놓는게 굉장히 복잡했고, 이전에 봐왔던 코드와도 너무 달라서 이해하기에 상당히 시간이 오래 걸렸다.

내가 너무 프론트적 발상(?) 그러니까, 그냥 단순히 '데이터를 가져오기만 하면 되는데 ~' 에서 생각이 멈춰 있는게 가장 큰 이유라고 생각하긴 한다.

그렇지만 이렇게 나누는 이유에 대해서 들었을때 어느정도 납득이 되기는 했다.

결국엔 유지보수, 확장성, 테스트 다 이 구조 때문에 좋아진다고 했는데 그게 무슨 말이냐 하면,

 

Supabase를 사용하다가 Firebase로 바꾸고 싶으면 Repository 만 바꾸면 나머지 코드는 수정하지 않아도 되고,

테스트할때 가짜 Repository만 넣으면 진짜 DB를 사용할 필요도 없다.

 

결국엔 한 부분만 바꾸고 싶을 때, 그 부분만 바꿀 수 있게 만드는 구조인 것이다.

 

4.  여섯번째 강의를 마무리 하며...

사실 요즘 블로그 글이 조금 뜸했다.

현재 내가 듣고 있는 멋쟁이 사자처럼 프론트엔드 심화 4기는 3월 25일부터 시작해 4월 4일까지의 간단한 이론수업을 진행 한 후 프로젝트를 진행하고 있다.

 

4월 7일 부터 프로젝트가 진행되고 있는데, 기획 부터 디자인, 코드 구현 그리고 발표준비까지 해야해서 시간이 정말 빠듯하다.

현재 진행하고 있는 프로젝트도 글로 정리하고 싶은데 최대한 짬이 나는데로 블로그에도 작성해보도록 하겠다.