coding etude
[Architecture] Clean Architecture 의 이해(1) 본문
오늘은 클린 아키텍쳐에 대해서 한번 정리해 보자.
Clean Architecture란 무엇인가?
Clean architecture는 앱 전체의 구조 설계를 정의하는 용어이다.
쉽게 말해서 내가 개발하는 프로덕트의 폴더구조를 뜻하는 것으로 폴더를 계층화 시키는 것으로,
말 그대로 '깨끗한 구조' 를 말한다. 왜 깨끗한, 깔끔한 구조라고 할까?
지금부터 자세히 알아보자.
Clean architecture는 왜 사용 하는가?
Clean architecture의 기본 개념이 위에서 설명한 계층을 분리하는것에 있다.
그렇다면 계층을 분리해서 사용하는 것의 목적은 무엇일까?
Clean architecture는 기분 적으로 의존성(DI)을 외부에서 주입 받아서 사용 하도록 한다.
이 말은, 계층별로 상위와 하위가 분리되고 의존성은 상위에서 하위로 흐르게 된다는 뜻이다.
그러므로 하위계층은 상위 계층에서 어떤일이 일어나는지 전혀 알 수 없고, 주어진 명령만 실행하면 되는 구조가 되는것이다.
이렇게 되면 mockup을 주입해서 테스트에 용이하고, 주어진 명령만 수행 하면 되기 때문에 외부영역과 철저하게 단절되어 유지보수가 쉬워진다. 이것이 Clean architecture를 사용하는 궁극적인 목표이다.
계층의 구조와 역할
기본 개념과 목표를 글로 표현하자면 너무 어렵게 느껴질 수 있다.
우선 각 계층이 어떻게 분리되고 어떤 역할을 하는지 다음 구조를 확인해 보자.
/project-root
── /domain
│├── /entities
│├── /repositories(inteface)
│└── /usecases
│
├── /data
│├── /models
│├── /repositories
│└── /datasources
│
├── /presentation
│├── /view
│├── /viewmodel (또는 bloc, controller, provider 등의 상태관리)
│└── /widgets(components)
│
├── /infrastructure
│├── /network
│├── /database
│└── /external
│
├── /di (dependency injection)
│
└── main(앱의 진입점)
위 폴더 구조와 같이 진입점으로 시작해 presentation, domain, data 영역으로 계층이 분리가 된다.
계층 | 역할 |
data | 서버와 연결 |
domain | 각 domain의 명령 실행 |
presentation | UI 영역 |
여기서 데이터의 흐름은 data > domain > presentation으로 흐르고 의존 주입 역시 동일한 순서로 흐르게 된다.
여기서 알 수 있듯 data가 가장 상위, presentation이 가장 내부의 계층이 되는것다.
각각의 계층에서는 주어진 역할만 수행하게 되기 때문에 유지보수 할 때 수정 사항의 영역만 핸들링 해주면 된다.
그럼 이제 각 계층에서 어떤 방식으로 의존성을 주입 받고 계층별로 어떤 방식으로 소통되고 진행 되는지 알아보자.
presentation(UI)
이 영역은 view의 역할을 한다. 말 그대로 user가 직접적으로 사용하는 영역이다. view 영역에서 사용자로 인해 이벤트가 발생하면 view model로 이벤트를 전달한다. 그럼 view model은 주입되어 있는 의존(domain)으로 다시 이벤트를 전달한다.
doamin
domain영역은 각 domain에서 요청하는 데이터를 수집, 가공해서 UI에 전달하는 역할을 담당한다.
domain에 속하는 각 영역별 기능을 알아보자.
구분 | 역할 |
use case | data 영역에 필요한 data를 요청하여 presentation에서 요청한 data로 가공하여 보내준다. |
entity | presentation에서 사용되는 data의 model(요청한 데이터를 검증 및 확인에 쓰임) |
repository | abstract로 data영역과 Brigde 역할을 담당. |
presentation 영역에서 실제로 이벤트를 받아오는 역할은 use case에서 담당한다. 이 use case 영역은 데이터를 요청하고 받아온 데이터를 가공해서 view model에 전달하는 역할을 한다. 이 과정을 조금 더 상세하게 풀어본다면
use case에서 repository를 통해 데이터를 받고, 그 데이터를 entity로 검증하고, 가공해서 view model로 반환시켜준다.
이 것이 도메인의 역할 이다.
data
실제로 서버와 소통하는 영역이다. 서버에 데이터를 요청하고 요청 결과에 따라서 domain으로 결과를 전달하는 역할을 한다.
구분 | 역할 |
model | 데이터를 변환하는데 사용. |
repository | domain의 abstract의 repository를 상속하여 실제 구현 하는 영역. |
data source | infrastructure/network를 연동하여 서버와 소통하는 역할. |
domain에서 요청된 데이터를 repository가 data source로 전달하면, data source에서 model을 활용하여 변환하고 network로 서버에 요청하고, 반환된 값을 다시 model을 활용하여 변환 후 repository를 통해 domain으로 전달 한다.
요약 정리
이 개념과 로직을 말로 전달 하기에는 너무 어렵고 무리가 있다고 생각한다. 다음 포스팅은 이 내용을 바탕으로 구현된 간단한 로직의 예시들을 보면서 설명할 예정이다. 그럼 이번 포스팅을 정리하면서 마무리 해보자.
1. clean architecture는 분리 계층 구조이다.
2. 각 계층은 외부 계층에 대해서 철저하게 분리된다.
3. 의조성의 흐름과 데이터의 흐름은 동일하다.
(Data > Domain > Presentation)
4. 계층의 분리와 의존성의 주입으로 테스트가 쉽고, 유지보수가 간결하다.
다음 포스팅은 예제를 보면서 이론을 숙지해보자!
끝.
'Flutter(Dart)' 카테고리의 다른 글
[flutter android] flutter gradle plugin migrate 하기 (0) | 2025.08.21 |
---|---|
[Architecture] Clean Architecture의 이해(2) (1) | 2025.07.31 |
[flutter error] Error connecting to the service protocol: (2) | 2025.07.30 |
[android] build.gradle의 버전 세팅하기 (8) | 2025.07.30 |
[Admob] admob bannerAd 로드 및 UI 구현하기 (0) | 2025.03.09 |