클린아키텍처(CleanArchitecture)는 모바일 개발에 도움이 되는가 ?
클린아키텍처란 말은 몇년전에 들었지만, 미루고 미루다 최근에 책을 읽고 많은 감동(?)을 받았던 기억을 되새기며…
결정을 최대한 미뤄라
책을 읽고난 후 머릿속에 잊혀지지 않는 문구네요 🤗
책을 읽기 전에는 서비스를 개발할 때 “이러한 기능이 필요하니 구조는 이렇게 잡고, DB 스키마는 이렇게 가져가야겠구나!”라고 생각하고 바로 시작했던거같아요.(항상 구조를 잡을 때 미리 결정을 할 필요없는 부분까지 이미 다 정하고 개발을 시작했었어요.)
그럼 책을 읽고난 후엔 ?
많은 변화를 가져다주었는데 가장 큰 두가지를 뽑자면
- 개발자는 계속 뽑는데 개발 효율은 왜 어느 순간 줄어들거나 유지되는가 ?
(사실 책과 많은 관련이 있지 않지만 경력이 좀 쌓이고 읽어서 그런지.. 이런 생각이 많이 들더라구요.) - 서비스 정책에 대하여 먼저 생각하고 정책에 영향을 주지 않는 것에 대해서는 결정을 최대한 뒤로 미루자!
서비스의 정책과 관련없는 것들
- 예를들면 DB를 어떤걸 사용할래?
- 데이터 저장은 어디다 할까?
의 결정은 뒤로 미루면서 정책과 이러한 것들의 의존성을 제거하고 개발을 시작하면, 서비스 정책의 변경에 대하여 변경이 쉬워지는 구조로 설계를 시작할 수 있어요.
스타트업은 서비스를 키우기 위해서 많은 실험도 하고 이 과정에서 수많은 변경이 필요한 상황이 많은데 이를 위해서 클린아키텍처를 적용하면 많은 도움이 될거라고 생각합니다. (변경이 쉬운 구조를 위해 딜라이트룸의 알라미 프로젝트는 클린아키텍처를 적용하고있어요!)
클린 아키텍처?
클린 아키텍처는 밥 형님이 쌓아온 개발 경험을 토대로 만들어진 개발 방법론이라고 생각해요.
(위 이미지는 책에서도 인터넷에서도 많이 보던 것이네요..!)
의존성은 외부에서 내부로 향하게 해야하며, 원의 중앙에 있을 수록 서비스 정책에 가깝고 변경에 대한 영향이 가장 크다 라고 밥 형님이 말했던거 같네요.
위의 그림을 토대로 모바일에서의 클린아키텍처 구조는 아래와 같은 모습으로 그릴 수 있겠네요.
- Presentation(UI영역)
- Domain
- Data(DB 등등)
크게 세가지 레이어로 나눌 수 있으며 Domain을 제외한 Presentation과 Data 레이어는 Domain 영역으로 의존성을 갖게 됩니다.
Domain
Domain 레이어에서 가장 중요한것은 핵심 업무규칙과 어플리케이션 업무규칙이에요.
- Entity — 서비스 직군에 대한 핵심 업무규칙을 제공
- Usecase —핵심 업무 규칙을 어떻게, 언제 호출할지 명시
예를들어 알라미의 경우 Entity는 알람으로 정의할 수 있어요. 유저는 알람 Entity를 통해 알람 울리기와, 알람 해제하기 기능을 사용할 수 있죠. 이러한 Entity 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출할지를 명시하는 것이 Usecase에요.
알라미의 Usecase를 나열하면
- 유저는 알람이 울리면 미션을 시작할 수 있다.
- 유저는 미션을 완료하면 알람이 해제된다.
등을 정의할 수 있겠네요.
Presentation
Presentation 레이어는 UI를 담당하며 앞서말한 “결정을 최대한 미뤄라”를 떠올리면 Domain 레이어 설계 후 결정해도 되는 레이어 입니다.
(해당 레이어의 변경이 절대로 Domain 레이어로 영향을 주지 않아요. 왜냐면 의존성의 방향이 Presentation에서 Domain으로 흐르기 때문입니다.)
Presentation 레이어에서는 원 안에 정의된것처럼 MVC, MVVM 등 다양한 어플리케이션 아키텍처가 적용되고, UIKit, SwiftUI 등 어떤 식으로 UI를 그릴지 결정하는 레이어입니다.
모바일은 UI의 변경이 실험 혹은 다양한 이유로 변경이 많은데, Presentation 레이어의 작업이 Domain에 영향을 주지 않으므로 편하게 변경할 수 있다는 장점이 있어요.
Data
Data 레이어는 데이터를 처리하는 레이어에요. 데이터가 저장되고, 불러오는 역할을 담당합니다. Data 레이어 또한 이곳에서의 변경이 Domain 레이어에 영향을 주지 않습니다.
해당 레이어에는 Realm, CoreData 등 어떤 DB를 사용할지, 혹은 서버를 통한다면 어떤 서버를 이용할지 정의하는 레이어에요.
Data 레이어에서 중요한 부분은 Domain(서비스 정책)과의 관계가 명확해야 합니다.
(Entity와 DB Model과 분리) Domain 레이어에서는 특정 데이터가 어디에 어떻게 저장되는지는 중요하지 않기 때문이에요.(업무 규칙만 잘 돌아가면 됨)
모바일 개발을 하다보면 DB를 교체하는 경우가 많으면 안되지만.. 생각보다 많았어요.
Realm -> CoreData 혹은 CoreData -> Realm, Local -> Server 등…
Presentation 처럼 Data 레이어의 변경이 Domain 레이어로 영향을 미치지 않아서 Data 레이어만 신경쓰면 되는 장점이 있네요 :)
정리하면.. 모바일에 어떤 도움이 될까?
모바일에서는 크게 세가지 컴포넌트를 결정할 수 있다.
- 서비스 정책을 먼저 결정한다.
- 서비스 정책을 위한 UI(화면)를 어떻게 표시할지 결정한다.
- 데이터 관리를 어떻게 할지 결정한다.
결정을 미루면 컴포넌트 간에 경계선을 만들 수 있으며 이를 기반으로 모바일 서비스의 유연성을 높일 수 있다.
즉, 각 레이어의 변경이 필요한 부분에 대하여 빠르게 대응하고 유연하게 대처하여 유저에게 더 좋은 경험을 빠르고 안전하게 줄 수 있다!
위는 책을 읽은 후 클린 아키텍처를 적용한 앱들을 운영하면서 떠오른 저의 주관적인 생각입니다!
🔥비난🔥 보단 다양한 피드백과 관심 부탁드립니다 (_ _) 🤗
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다
딜라이트룸에 어떤 포지션이 있는지 궁금해요(+ 입사 축하금 100만원)
딜라이트룸 미디엄 팔로우하기 (카테고리 섹션 오른쪽의 ‘Follow’ 버튼 클릭)
