-
Notifications
You must be signed in to change notification settings - Fork 0
Clean Architecture에 Builder 넣기를 실패하기까지..
저희 팀은 Clean Architecture와 MVVM-C을 사용할 생각입니다. 각각의 역할 분리가 확실하게 되어있어서 유지보수와 부작용(side effect)를 줄일 수 있을 뿐더러, 무엇보다 protocol로 결합도를 줄여 테스트에 용이하게 만들 수 있다고 생각했습니다.
💭 흠… 오케이 그러면 Coordinator를 누가 갖고 있는게 맞을까?사실 여기서 고민을 꽤 많이했습니다. 각자 다른 의견을 갖고 있었고, 정답은 없는 문제였기 때문이었어요.
저희가 의논했던 부류는 세 가지였습니다.
화면의 흐름은 결국 ViewController에서부터 시작되고, 화면의 흐름은 결국 View와 관련되어 있다. 따라서 ViewController가 갖고 있어야 하지 않을까요?
맞는 말입니다. 결국 화면을 옮기는 코드는 ViewController가 해주어야하기 때문인데요.
여기서 제가 걱정하는 문제는 화면을 옮기는 코드도 역시 로직이라고 생각했고, ViewController를 View로 보는 입장에서는 썩 좋아보이지는 않았습니다.
그리고 ViewModel과의 관계가 애매해지는 것도 있습니다. ViewController에 Input이 들어오면 ViewModel이 받아 알아서 처리한 뒤 나온 결과값(Output)을 받는 구조인데, Coordinator를 ViewController가 갖게 된다면 이런 패턴을 따르지 않는 단독 구조가 될 것이 자명했습니다.
이렇게 하면 ViewModel과 View간 Input, Output 구조를 따르면서 값을 전달해줄 수 있겠죠. ㅎㅎ
하지만 우리(라고 쓰고 나라고 읽는다)가 원하는 건 ViewModel은 ViewController와의 데이터 바인딩만의 역할을 해주길 원했지만, 화면 전환 로직을 ViewModel이 갖게 되면 View에서 언급했던 문제처럼 로직을 ViewModel이 처리하는 것이라고 생각했어요. 그래서 모든 비즈니스로직을 Usecase에서 다루게 할 우리~~(나)~~의 목적과는 다르다고 느꼈습니다.
그래서 저희는 모든 로직 담당과 판단을 UseCase가 수용하기로 결정했어요. 그래서 Coordinator도 UseCase가 가지는 쪽으로 결정을 내렸습니다.
맞아요. Coordinator는 화면전환을 하는 로직이라고 귀가 닳도록 얘기했습니다. 그래서 View는 무조건 알고 있어야해요. 근데 Coordinator는 Usecase와 서로 통신하고 있기 때문에 구조 자체적으로 본다면 View를 알 수가 없습니다. 그래서 구조를 만들기 전에 누군가가 나서서 모든 것을 주입해주고 연결해 주어야 하는데요. 이 때 DI Container와 동일한 역할을 해주는 Builder를 사용하여 해결할 수 있다고 생각했습니다.
이렇듯 Builder가 필요한 모든 구성요소를 만들어주고, Coordinator는 그걸 가지고 화면 전환을 구성하면 완벽한 전략이겠다..! 라고 생각했어요. 그래서 RIBs를 참고해서 Builder를 구성해보았습니다.
그리고 테스트를 위해 버튼을 누르면 다음 화면으로 넘어가는 매우매우 간단한 플로우를 구성해보았습니다.
근데 생각보다 하나의 구조를 만들 때마다 5개의 파일이 생성되었고, 복잡성이 올라갔습니다. 심지어 Repository를 따로 넣지도 않았는데도요.
그 뿐만이 아니었습니다. 세 가지의 문제가 있었는데요.
첫째, RIBs
아키텍처를 참고해서 만들었다보니 러닝 커브가 꽤나 클 것이 분명했고, 6주라는 짧은 기간 내에 아키텍처를 습득하고 바로 적용하기에는 빠듯한 시간이었습니다.
둘째, RIBs
체계와 Clean Architecture
를 혼합해서 사용하려고 하니 너무나도 큰 오버엔지니어링이라고 생각했어요. 비교적 간단한 로직이 들어갈 곳인 경우에도 순수 Clean Architecture
보다 더 많은 파일들이 생기니까요.
셋째, UseCase
가 RIBs의 Interactor
로 변모하고, Coordinator
가 RIBs의 Router
로 변모하는 모습이 보였습니다. 이렇게 될 거였다면 그냥 RIBs를 사용하는 것이 더 편리했을테고, Clean Architecture 구조까지 사용하면서 발생하는 큰 이점은 무엇이 있을까를 고민해야 했습니다.
저는 이 세 가지의 문제를 해결하기 위한 방안을 답하지 못했고, 아이디어는 잠시 깊은 수면 속으로 넣어둔 상태입니다..