• Modular Architecture
• 문제가 많아 보이는 현재 구조
• CoreKit의 의존성은 어디를 향해야 하는가
• 갈팡질팡 Domain 레이어
• Shared Model 방법
• Repository 프로토콜 방법
• 선택은..?
• UseCase는 그럼 언제 써야하지..?
• 마치며

Modular Architecture

MusicSpot 프로젝트는 모듈러 아키텍처를 채택해서 사용했습니다.

하지만 사실 "모듈러 아키텍처"의 어떤 장점을 살리겠다 는 점 보다는

분리된 각 레이어를 강하게 분리시켜서 import하지 않으면 사용할 수 없도록

아주 강한 제약을 두고 각 레이어에 대해 학습하겠다!

측면이 강했습니다.

그렇다면 그 목적에 맞게 각 레이어의 독립이 아주 잘 이루어졌어야겠죠?

과연 그랬을까요?

문제가 많아 보이는 현재 구조

지난 프로젝트를 돌아보며, 과연 모듈러 아키텍처의 채택 목적에 맞게

아키텍처를 "잘" 사용하고 있을까? 를 돌아보기로 했습니다.

그래서 Dependency 그래프를 한 번 그려봤습니다.

(저희 앱은 Tuist를 사용하고 있지 않기 때문에, 한땀한땀 그려줘야 했습니다.)

네.. 많이 어지럽네요 ㅎ..

이를 조금 (많이) 단순화 시켜보면 아래와 같아집니다.

여기서 제게 생긴 의문점은 크게 세가지입니다.

1. Feature 패키지 중 MSCoreKit의 기능을 직접 가져다 쓰는 부분이 있다. 직접적으로 사용하는 대신 MSData에서 사용하는 것이 바람직하지 않은가?
2. Feature 패키지가 MSData와 MSDomain 레이어를 모두 의존하고 있다. MSDomain 레이어는 지금 형태가 최선인가?
3. MSFoundation 패키지, 특히 Logger의 경우 모든 패키지가 구분 없이 의존성을 갖고 있다. 괜찮은건가?

하나하나 고민해봅시다.

CoreKit의 의존성은 어디를 향해야 하는가

가장 큰 고민을 가지고 있는 부분입니다.

CoreKit의 로직들이 Feature 모듈들에 열려있어도 되는가? 에 대한 문제입니다만

Clean Architecture의 어떤 레이어와 연관성이 높은 지 부터 살펴보겠습니다.

저희가 내렸던 CoreKit에 대한 정의는 다음과 같습니다.

앱의 핵심적인 로직들이 포함된 모듈

네트워킹, 캐싱, 로컬 파일 저장 등 비교적 리소스를 많이 잡아먹는 로직들이 포함됩니다.

또, 한 가지 공통점이 하나 더 있는데, 지금까지는 어떤 형태로든 데이터를 휙득하거나 가공하는 로직들이 포함되어 있다는 것입니다.

그렇기 때문에 Presentation 레이어보다는 Data 레이어와의 연관성이 훨씬 높습니다.

여기까지가 Data 레이어가 CoreKit 모듈을 의존해야하는 이유였고, 이제부터는 Feature 모듈들에서의 이야기입니다.

Presentation 레이어에서 CoreKit의 로직을 왜 필요로 하고 있을까요?

가장 대표적인 예시입니다.

self.imageView.ms.setImage(url: someURL)

ImageFetcher 모듈의 UIImageView에 대한 extension을 활용한 방식입니다.

이 문제는 다행히 ms로 wrapping한 부분을 UI 모듈쪽으로 분리하는 것으로 쉽게 해결할 수 있었습니다.

근본적은 물음에 대한 답은 어떻게 내리면 될까요?

Presentation 레이어에 해당하는 Feature 모듈들은 CoreKit에 대한 의존을 가져도 되는가?

CoreKit을 모듈화하고, Data 레이어에 의존성을 부여하는 것에 대한 장점을 정리해보면 좋을 것 같습니다.

1. 최외곽인 Presentation 레이어에서 로직에 대한 관심을 끊어낼 수 있습니다. 이후 로직이 변경되더라도 추상화한 Protocol이 바뀌지 않는 한 Presentation 레이어의 변경점은 없습니다.
2. Presentation 레이어에 Repository를 주입시켜주는 것 만으로도 테스트가 가능하다.

제가 생각하는 가장 큰 이점은 이 두가지입니다.

쉽게 말하면 1. 약한 결합과 2. 테스트 용이성입니다.

그렇다면 이 장점을 반대로 말하면 Feature 모듈이 CoreKit에 의존할 경우 발생하는 문제점이 되겠죠?

1. CoreKit의 로직이 변경될 경우, 이 로직을 사용하는 모든 Feature 부분의 코드에 변경이 가해져야 한다.
2. Presentation 레이어의 테스트를 위해 CoreKit을 필수적으로 import 해야한다. 즉, CoreKit의 변화가 CoreKit 자체의 테스트뿐만 아니라 ViewModel의 테스트에도 영향을 준다.

결국 단점은 CoreKit의 변화가 파편화 된 코드들에 영향을 주고, 변화를 강제한다는 것 입니다.

갈팡질팡 Domain 레이어

두 번째 주제, Feature 모듈들이 Data 레이어와 Domain 레이어 모두를 의존하고 있는데, 괜찮은건가? 입니다.

이 주제에 대해 이야기하기 전에, 저희 앱은 UseCase를 사용하고 있지 않습니다.

그 필요성을 느끼지 못했기 때문인데요..

따라서 Domain 레이어에는 사실상 Entity만 포함되어 있습니다.

때문에 Repository의 로직을 사용하기 위해 Data 레이어를, Entity 모델들을 사용하기 위해서 Domain 레이어를 모두 의존하고 있는 것이죠.

그렇다고 단순하게 Presentation 레이어가 Domain 레이어만을 의존하도록 만들기 위해 UseCase를 도입하는 것은 도입의 이유로서 타당하지 않다고 생각합니다.

하지만 그렇다고 현재 구조가 올바른가? 하면 그것도 아니라고 생각합니다.

Feature 레이어에서 Data 레이어의 DTO와 같은 원하지 않던 요소들에도 접근이 가능해지기 때문입니다.

그렇다면 Domain 레이어 자체를 손봐야겠죠..?

자, 이쯤에서 다시 한 번 현재 구조를 살펴봅시다.

저희 구조 상 한가지 특이한 점이 있는데요, 바로 Domain 레이어가 다른 어떤 모듈도 의존하지 않고 있다는 점입니다.

앞서도 말했던 Entity 모델만이 Domain 레이어에 존재하기 때문인데요, 그렇다면 굳이 Domain 레이어가 필요할까요..?

이 문제를 해결하기 위해 두 가지 방법을 생각해봤고, 직접 실행해봤습니다.

1. Domain 레이어를 제거하고 Feature 모듈들을 하나의 모듈로 묶은 후, Shared Model 라이브러리를 추가한다.
2. Data 레이어에 있는 Repository protocol들을 Domain 레이어로 옮긴다.

Shared Model 방법

UseCase가 없는 Domain 레이어를 과연 Domain 레이어라고 부를 수 있을까라는 의문에서 시작된 해결법입니다.

Feature 레이어를 하나의 패키지로 묶고, Shared Model 이라는 라이브러리를 만들어서 다른 모듈들이 의존성을 갖도록 해줬습니다.

그런데 단순히 이 형태로는 Data 레이어의 다른 요소들에 접근 가능한 문제점을 해결하지 못했습니다.

Repository를 사용할 수 있어야하기 때문에 여전히 Data 레이어에 대한 의존성이 제거되지 못하고 있습니다.

그래서 Data 레이어 내부에서도 라이브러리를 나눠보았습니다.

Repository의 추상화를 위한 프로토콜을 별도의 모듈로 분리해주고, Feature 레이어는 해당 라이브러리만을 의존하도록 변경한 버전입니다.

추상화 프로토콜이 별도의 라이브러리로 존재해야한다는 점만 제외하면 꽤 합리적인 방안이라고 생각합니다.

Feature 모듈들은 Data 레이어 중 필요한 부분만 의존하게 되었고, Data 레이어 또한 Entity만을 의존하면서 단독 테스팅이 가능한 형태가 되었습니다.

Repository 프로토콜 방법

현재 형태를 최대한 유지하면서 Feature 레이어가 Data 레이어에 대한 의존성을 끊을 수 있는 방법을 고민하면서 나온 방법입니다.

Feature 모듈이 필요로 하는 Data 레이어의 요소는 정확히 무엇일까를 생각해보면..

앞선 방법에서도 보였듯이 사실은 Repository의 추상화 프로토콜만 필요합니다.

그러면 해당 프로토콜만 Domain 레이어로 옮겨오면 되지 않을까!? 라는 아이디어에 도달한 것이죠!

그렇게 도달한 결과가 위 형태입니다.

Feature 모듈들 (Presentation 레이어) 는 Domain 레이어에 대한 의존성을 가짐으로써 공용으로 사용되는 Entity와 Data 레이어의 로직들을 호출할 수 있습니다.

하지만 동시에 Data 레이어의 구현부가 아닌 Protocol만 알고 있기 때문에 구현부에 대한 직접적인 의존성은 끊어낼 수 있었습니다.

Data 레이어 또한 마찬가지로 Entity를 알고 있기 때문에 독립적으로 로직을 가질 수 있게 되었고, DTO에서 Entity로 변환하는 로직 또한 자연스럽게 가질 수 있게 되었습니다.

이 방식이 올바른 지 찾아보던 중에 발견한건데... 이 형태가 일반적으로 많이 쓰이는 형태인 것을 발견했습니다.

일반적으로는 Domain 레이어에 UseCase를 쓴다는 큰 차이점이 있긴 하지만요..?

선택은..?

저희 앱의 경우는 두 형태 모두 적절하다고 판단했습니다.

1. 변경되는 사항이 후자의 경우가 훨씬 적다.
2. 이후 UseCase가 추가되어야 할 경우 두 번째 형태가 훨씬 변경에 용이하다.

두 경우 모두 적용을 시도해보았습니다.

첫 번째 방법의 경우, 생각보다 구조의 변경이 많이 일어나야 했습니다.

Feature 모듈들이 하나로 묶여야 한다는 점이 생각보다 꽤 큰 작업이였습니다.

무엇보다 (물론 이것도 제 부족이겠지만) CI의 형태도 극단적으로 바뀌어야 했습니다..

또한 이후 UseCase의 필요성을 느끼게 되고, Domain 레이어에 대한 필요가 더욱 커지게 되는 경우에도 후자의 경우가 훨씬 변경에 용이한 구조를 갖고 있습니다.

어찌됐건 Domain 레이어가 유지되는 방향이니까요..!

그래서 저희는 후자의 경우, Repository 프로토콜을 Domain 레이어로 옮기는 방법을 택하게 되었습니다.

UseCase는 그럼 언제 써야하지..?

여기까지 도달하면서 계속해서 생긴 의문은 "그럼 대체 UseCase는 언제 써야하지?" 였습니다.

나름대로 내린 결론이 있습니다.

반복되는 비즈니스 로직이 많아지면 UseCase의 도입에 대한 요구가 생길 것이다. 입니다.

저희 앱의 경우 아주 작기 때문에.. 반복되는 비즈니스 로직이 없는 상태입니다.

정확히 말하자면 있을 수는 있지만 인지하지 못할 만큼 그 규모가 크지 않다. 가 맞는 말인 것 같네요.

개인적으로 UseCase의 도입 자체는 테스트나 기타 구조 상의 이점을 주는 것 같지는 않습니다.

이 생각도 언젠가는 바뀔 수도 있겠죠? 😊

마치며

아키텍처를 직접 몸으로 부딪혀가며 느낀 점은, 결국 아키텍처 설계라는 것은 편의성을 위해서라는 겁니다.

오버 엔지니어링이 될 수도 있다는 위험도 언제나 도사리고 있지만, 아키텍처를 변경해야겠다는 느낌은 분명 어딘가 "불편" 한 상태이기 때문일겁니다.

접근되어서는 안되는 메서드나 프로퍼티가 계속해서 접근 가능해서 불편하거나,

테스트에 필요한 의존성들이 많아져서 불편하거나..

이런 불편함들을 해소하고자 아키텍처를 설계하는 것이라는 생각을 가지게 되었습니다.

그렇다고 마구잡이로 설계해서는 또 안됩니다.

미래에 어떻게 어떤 부분이 변경될 지 모르기 때문에, 최대한 확장에 열려있고 변경에 유연하게 대처 가능해야 합니다.

그러다보니 여러 복잡한 이론들이 계속해서 생겨나고, "모던" 한 아키텍처란 무엇인가 끊임없이 토론되는 것 같습니다.

왜 아키텍처를 설계하고 있는 지 그 이유를 항상 옆에 두고 고민해야하는 주제인 것 같아요!