Feature의 병렬적인 모듈화를 위한 ViewController 추상화 방법

[L-j-h-c]

현재 Presentation으로 단일화된 상태에서 Scene Flow 별로 Features를 분리하는 작업 중에 있습니다.

아래와 같은 시나리오를 생각해 보았습니다!

1. 앱 구현 특성 상 서로 다른 Feature의 명세가 필요할 때가 있습니다. 이때 구현 모듈이 서로를 직접 참조하게 되면 순환 참조가 생길 수도 있고, 모듈 간의 결합도도 강해집니다. 따라서 구현 모듈 간에 직접 의존하지 않게 만들기 위해 Interface 모듈을 도입했습니다.
2. Interface 모듈 내부에는 ViewController를 추상화 할 수 있는 Protocol을 정의하여, 다른 Feature에서 참조하여 viewController를 생성할 수 있도록 하고자 했습니다.
3. 추상화된 인터페이스와 의존성의 조립은 App Module에서 이루어집니다.

BaseFeatureDependency

ViewController를 가져올 수 있는 protocol을 작성합니다.

import UIKit

public protocol ViewRepresentable {
    var viewController: UIViewController { get }
}

public extension ViewRepresentable where Self: UIViewController {
    var viewController: UIViewController {
        return self
    }
}

Main Feature

Interface

ViewRepresentable을 채택하는 MainViewRepresentable을 정의합니다.
MainView가 가져야 하는 다른 속성도 함께 정의 가능합니다. 현재는 ViewController의 추상화와 생성에만 집중했습니다.

makeMainView에 값 전달이 필요한 경우 parameter를 사용 가능합니다.

import BaseFeatureDependency

public protocol MainViewRepresentable: ViewRepresentable { }

public protocol MainViewBuildable {
    func makeMainView() -> MainViewRepresentable
}

Target

MainViewRepresentable을 채택한 구현체를 만들어주고, AuthViewBuildable의 의존성으로 authView 생성하도록 합니다.

import UIKit

import MainFeatureInterface
import AuthFeatureInterface

public final
class MainViewController: UIViewController, MainViewRepresentable {
    public var factory: AuthViewBuildable!
}

extension MainViewController {
    func presentAuthView() {
        let authView = factory.makeAuthView().viewController
        self.present(authView, animated: true)
    }
}

AuthFeature

Interface

import BaseFeatureDependency

public protocol AuthViewRepresentable: ViewRepresentable { }

public protocol AuthViewBuildable {
    func makeAuthView() -> AuthViewRepresentable
}

Target

import UIKit

import AuthFeatureInterface

public final
class AuthViewControlelr: UIViewController, AuthViewRepresentable { }

App

DIContainer

의존성을 관리할 Container를 만들어 줍니다.

import AuthFeatureInterface
import AuthFeature
import MainFeatureInterface
import MainFeature

typealias AppBuildable = AuthViewBuildable & MainViewBuildable

final class DIContainer {
    
}

extension DIContainer: AppBuildable {
    func makeAuthView() -> AuthViewRepresentable {
        let authViewController = AuthViewControlelr()
        authViewController.view.backgroundColor = .blue
        return authViewController
    }
    
    func makeMainView() -> MainViewRepresentable {
        let mainViewController = MainViewController()
        mainViewController.factory = self
        mainViewController.view.backgroundColor = .gray
        return mainViewController
    }
}

SceneDelegate

import UIKit

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?
    
    var container = DIContainer()

    func scene(_ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions) {
        guard let scene = (scene as? UIWindowScene) else { return }
        
        window = UIWindow(frame: scene.coordinateSpace.bounds)
        window?.windowScene = scene
        let rootVC = container.makeMainView().viewController
        window?.rootViewController = UINavigationController(rootViewController: rootVC)
        window?.makeKeyAndVisible()
    }

    func sceneDidDisconnect(_ scene: UIScene) {}

    func sceneDidBecomeActive(_ scene: UIScene) {}

    func sceneWillResignActive(_ scene: UIScene) {}

    func sceneWillEnterForeground(_ scene: UIScene) {}

    func sceneDidEnterBackground(_ scene: UIScene) {}
}

[L-j-h-c]

@elesahich @lsj8706 @devxsby @0inn
피드백 부탁드립니다 선생님들...!

[lsj8706]

자세한 설명 정말 감사합니다!!
궁금한 점이 있는데 이렇게 되면 생성하는 모든 VC에 Representable과 Buildable 인터페이스를 각각 생성해야 하는 건가요?
아니면 다른 Feature에서 참조가 필요할 것이라고 생각되는 VC에서만 이러한 인터페이스를 생성하면 되는 것일까요..?
인터페이스 모듈 분리를 통한 의존성 관리 신기하네요 ㅎㅎ

[L-j-h-c]

App Model에서 의존성을 조립해야 하기 때문에 MainFeatureBuildable에 모든 VC를 생성할 수 있는 메서드를 두면 될 것 같아요!

[0inn]

각 FeatureInterface에 해당 Feature에 존재하는 VC를 생성할 수 있는 메서드를 두라는 뜻이 맞을까요 ?

[L-j-h-c]

@0inn 넵넵 각 FeatureInterface에 해당 Feature에 속하는 VC를 생성할 수 있는 메서드를 두면 될 것 같습니다!

[elesahich]

오늘 예비군이어서 틈틈히 쓰려고 했는데 슬쩍 보고는 핸드폰으로 쓸 양은 아니군 하며 살며시 닫았습니다요. 그래서... 늦었네요... ^^
열심히 공부한 것 같아서 멋지고요, 공부한 것을 잘 정리해서 말씀해 줘서 고맙고 멋집니다. 의견도 잘 이해 했어요! 천천히 읽다 보니 하나 제안할 것이 보여서요. 어떤 것이냐면,

public final
class MainViewController: UIViewController, MainViewRepresentable {
    public var factory: AuthViewBuildable!
}

이 부분을

public final
class MainViewController: UIViewController, MainViewRepresentable {
    private let factory: AuthViewBuildable

    init(authBuildable builder AuthBuildable) {
       self.factory = builder // 그리고 이름은 Builder가 어떨까 합니다 (Needle Example에서 builder로 쓰고 있거든요.)
    }
}

이렇게 개선하면 어떨까요? 물론 이렇게 하려면, 의존성 트리를 잘 구현해야 하고요, 잘 정렬해야 해요. 그러려면 인터페이스 말고 buildable을 구현할 구현체가 하나 있으면 좋겠네요! 예를 들어,

public protocol MainViewRepresentable: ViewRepresentable { }

public protocol MainViewBuildable {
  func makeMainView() -> MainViewRepresentable
}

public class MainViewComponent: MainViewBuildable { // NEW
  var authViewBuildable: AuthViewComponent: {
    AuthViewComponent()  
  }

  public func makeMainView() -> MainViewRepresentable {
    MainViewController(
      authViewBuildable: self.authViewBuildable
    )
  }
}

public final class MainViewController: UIViewController, MainViewRepresentable {
   private let factory: AuthViewBuildable 

   // 이니셜라이저를 만들어잉
}

이런 형태가 되어야 겠죠? 그러면

public final class DIContainer {
  var mainViewBuildable: MainViewBuildable {
    return MainViewComponent()
  }
}

이런식으로 선언할 수 있고,

func scene(_ scene: UIScene,
    willConnectTo session: UISceneSession,
    options connectionOptions: UIScene.ConnectionOptions) {
    guard let scene = (scene as? UIWindowScene) else { return }
        
    window = UIWindow(frame: scene.coordinateSpace.bounds)
    window?.windowScene = scene
    let viewController = self.diContainer.mainViewBuildable.makeMainView().viewController
    
    window?.rootViewController = UINavigationController(rootViewController: rootVC)
    window?.makeKeyAndVisible()
}

이렇게 이용하게 됩니다.

차이는 어떤 것이냐면 :

• 각 모듈 또는 ViewController를 생성하는 곳에서 FooComponent라는 FooBuildable에 대한 구현 객체를 가지게 됩니다!

위 예시는 어떤 점을 개선하냐면 :

• factory IUO 변수를 개선할 수 있습니다
• Component (이름은 가제 - 이것도 Needle에서 이래 쓰긴 합니다) 객체가 builder의 구현체로서 ViewController의 생성을 담당합니다. 생성 주체가 바뀌는 것 같으니 이 점을 한번 잘 보길 바래요
• 의존성 트리는 중요한데요 이렇게 하면 생성 책임이 명확하므로 자연스레 트리를 그리게 됩니다

어떤 불편한 점이 있냐면 :

• 보일러플레이트가 생깁니다. 각 뷰 컨트롤러마다 Component 객체를 생성해야 하므로. 근데 이건 Xcode Template 같은 걸로 개선할 수 있음.

이런 식입니다. VIewRepresentable은 Ribs의 그것인 것 같으니, Uber의 Needle이 아주 짝이 잘 맞거든요. 이것도 천천히 공부해 보세요!
부끄럽지만 이런 프로젝트도 있고요. 질문도 편히 주세요 :-)

[L-j-h-c]

우선 바쁘신 와중에도 상세한 피드백과 설명 너무 감사드립니다 😄😄

말씀해주신 대로 Component를 만들어 생성의 책임을 지는 구현체를 두게 되면, 최상위의 DIContaier가 가진 너무 많은 역할을 분리할 수 있어 좋겠군요!
다만 우려되는 점은, 현재 모듈 구조상으로 Feature 모듈은 Data 모듈을 모르고 있습니다.

따라서 기존에 앱 모듈에서 makeMainView 내부에 service, repository를 주입해주던 방식이 불가능할 것 같아요.
아래는 현재 앱에서 의존성을 조립하는 방식입니다.

import Foundation

import Core
import Presentation
import Network
import Domain
import Data

public class ModuleFactory {
    static let shared = ModuleFactory()
    private init() { }
    
    lazy var authService = DefaultAuthService()
    lazy var userService = DefaultUserService()
    lazy var rankService = DefaultRankService()
    lazy var missionService = DefaultMissionService()
    lazy var stampService = DefaultStampService()
    lazy var firebaseService = DefaultFirebaseService()
}

// MARK: - Onboarding / Auth

extension ModuleFactory {
    public func makeSplashVC() -> Presentation.SplashRepresentable {
        let repository = AppNoticeRepository(service: firebaseService)
        let useCase = DefaultAppNoticeUseCase(repository: repository)
        let viewModel = SplashViewModel(useCase: useCase)
        let splashVC = SplashVC()
        splashVC.factory = self
        splashVC.viewModel = viewModel
        return splashVC
    }

혹시 이러한 문제는 어떻게 풀어가면 좋을까요?
당장 떠오르는 방식은 MainViewBuildable 내부에 AuthViewBuildable의 명세만 두고, 구현은 앱 모듈에서 하는 방향입니다.

또는 data 모듈을 Feature 하부에 둘 수도 있을 것 같은데, 클린 아키텍쳐를 지향하고 있기에 Feature가 직접 data를 알게 되면 결합도가 강해지는 것이 아쉬워지기도 합니다 ㅜㅜ

[devxsby]

잘 보았습니다. 좋은 의견 감사합니다... .. 알림 가나..