서론
최근 들어서 프로젝트의 설계와 구조에 대한 관심이 컸었고,
이에 대한 계기는 Funch 프로젝트의 개발 과정에 있다
현직자 형이랑 같이 개발을 하는데 무슨 레이어.. 저런 레이어.. 등등..
초반에는 전혀 이해도 안되는 이야기를 하길래 조금 절망스럽기도 했다
하지만 여기서 끝내면 이성민이 아니지 ㅋ
프로젝트 중에는 개발하느라 바빴고,
끝나자마자 Clean Architecture를 공부하기 시작했다
가장 괜찮은 공부 방법이 '그' 클린 아키텍쳐 서적을 읽는거였는데,
아니나 다를까 전혀 이해가 안됐고 ... 내 또다른 멘토 형이랑 밥 먹으면서
객체지향부터 공부해보면 좋을 것 같아서 책을 추천 받았다
-> <객체지향의 사실과 오해>
책은 다 읽었는데 면접, 코테, 취준 하느라 5장부터 블로그를 못썼는데,
조만간 다시 시작할 예정 ...
무튼 책을 읽고 클린아키텍쳐를 다시 생각해보니 ...
꽤나 흥미롭게 책임과 역할과 협력을 대입해가면서 분석할 수 있었다
이걸 공고 지원서에도 많이 썼고, 면접을 앞두고 있는데,
그 전에 스스로 한 번 정리하는 차원에서 글을 쓰게 됐다
본론
결국 iOS 개발을 하는 이유가 서비스를 제공하기 위해서이고,
그 서비스에 Clean Architecture를 적용하려고 하는거다
그래서 상세적인 레이어로 들어가기 전에 서비스를 사용하는 유즈케이스와
서비스가 담당해야 하는 책임, 협력 등에 대해서 살펴보겠다
가장 거시적인 측면 - 서비스
사람들이
서비스, 또는어플리케이션을 왜 사용할까 ?
즉, 사용자들의 서비스를 사용함에 있어서의유즈케이스는 뭘까?
위 질문에 대해 가장 먼저 생각을 해봤다
그래서 내가 나름대로 생각한 유즈케이스는 아래와 같다
특정 목적의 실행 ( 사실 유즈케이스 자체의 의미인 것 같긴 하다만... )
왜냐하면 ... 카카오톡이나, 네이버나, 29CM이나.. 등등
주된 서비스의 사용 이유는 (상세적인 것은 다르겠지만) 특정 목적을 실행하는 것이다
- 카카오톡을 통해서 지인과 원격으로 대화하기
- 네이버를 사용하면서 검색, 쇼핑, 뉴스 등등을 통해 정보를 얻기
- 29CM을 통해 쇼핑하기
하지만 이렇게 서비스를 하나의 객체라고 생각하면, 너어어어어어무 많은 책임을 갖는다
조금 더 깊게 들어가기 - 레이어
너무 많은 책임을 조금 분산시키기 위해, 목적의 실행이라는 책임을 조금 나눠보겠다
- 목적을 수행할 수 있는 화면을 보여준다 ->
Presentation Layer- 목적을 수행한다 ->
Domain Layer
이렇게 생각해보면 목적의 실행이
Presentation 과 Domain 사이의 협력관계로 생각할 수 있다
Domain에서는 목적을 수행하고
Presentation에서는 유저에게 목적을 수행하기 위한 요소들을 보여준다
.
그래서 사실 볼륨이 작은 서비스들은 이 두 레이어만 있어도 되지 않을까라는 개인적인 생각이다
하지만 생각해보면, 목적을 수행하기 위해서는, 대부분 특정 정보를 보여줘야 한다
즉, 내부/외부 데이터베이스로부터 정보를 가져와야한다
이런 관점에서, Domain 레이어를 다시 두 가지 책임으로 나눈다
- 특정 정보를 사용/가공하여 목적을 수행한다 ->
Domain Layer- 정보를 가져온다 ->
Data Layer
.
이렇게 생각해보면, Clean Architecture의 세 가지 레이어의 책임이 나온다
Presentation- 목적 수행을 위한 화면을 보여준다Domain- 특정 정보를 사용/가공하여 목적을 수행한다Data- 특정 정보를 가져온다
이를 협력관계로 보면 아래와 같다
Presentation-Domain: 유저와의 상호작용을 통해 특정 정보를 보여주며 가공한다
Domain-Data: 특정 정보를 보여주고 가공하기 위해 외부/내부로부터 정보를 가져온다
조금 조금 더 깊게 들어가기 - 각 레이어
Presentation 레이어
Presentation은 결국 화면을 보여주고, User Interaction을 처리해야 한다
즉, 화면에서 보여지는 모든 것을 해야한다
이렇게 보면, Presentation 또한 너무 많은 책임이 있어서 나눈다 !
- 화면을 보이기 ->
View- 화면에서의 Interaction을 처리하기 ->
ViewModel- 화면에 정보를 띄우기 ->
Model->Domain의 Entity
(MVVM 측면에서의 분리이다, 다른 패턴을 쓴다면 당연히 달라질 것이다)
기본적은 MVVM 측면에서는 이렇게 생각할 수 있다
여기에 추가적으로 Coordinator나, DIContainer등을 사용해서 책임을 더 분산시킬 수 있을 것 같다 !
Domain 레이어
Domain은 특정 정보를 사용/가공하여 목적을 수행해야 한다
즉, Data 레이어로부터 정보를 가져오고, 이를 가공하고 사용해야 한다
이 또한 단일 객체에서 담당하기에는 책임이 막대하기 때문에, 나눈다 !
- 화면에 보일 정보의 형태 ->
Entity- 정보의 가공 및 사용 ->
UseCase- 정보를 가져오기 ->
Repository->Data의 Repository
Data 레이어
Data는 특정 정보를 가져와야 한다
어디서? 데이터베이스에서
어느 데이터베이스에서? 내부? 외부?
이렇게 서로 아는 것이 다르기 때문에, 나눈다 !
- 정보를 가져오는 것을 요청하는 부분 ->
Repository- '외부' 데이터베이스와 연결되는 부분 ->
Network(이름 개인차 有)- '내부' 데이터베이스와 연결되는 부분 ->
Persistent Storage(이름 개인차 有)
결론
이렇게 보면, 얼추 우리가 아는 Clean Architecture의 형태가 된다
프로젝트 볼륨, 의도, 또는 다른 아키텍쳐 적용 여부에 따라 각 역할과 책임과 협력관계가 달라질 수 있겠지만
나는 Clean Architecture에서는 이렇게 분석해보았다
처음 Clean Architecture가 나온 의미가 이와는 다를 수 있겠지만 머 ...
무튼 분석하면서 해당 아키텍쳐에 대해 훨씬 자세하게 이해할 수 있었던 것 같다 !
이후로도 책임과 협력과 역할 측면에서 쭉 분석해봐야겠다 !
