Chore/#1 tuist/fastlane setting#2
Conversation
There was a problem hiding this comment.
Feature - Data/Domain - Core - Shared로 이어지는 레이어 설계가 좋습니다. 특히 ThirdPartyLibs를 별도로 두어 외부 라이브러리 의존성을 한곳으로 모은 점은 프로젝트 전체의 빌드 세팅을 단순화할 수 있을 것 같습니다.
현재 구조에서 BaseFeatureDependency가 DSKit과 Domain에 모두 의존하고 있습니다. 프로젝트가 커질 경우 BaseFeatureDependency가 너무 비대해지는 현상이 발생할 수 있습니다. 각 Feature가 필요한 Domain만 선택적으로 가질 수 있도록 추후 Domain 레이어를 기능별로 세분화하는 것을 고려해볼수 있을 것 같습니다.
Data 모듈이 Networks와 Domain에 의존하고 있는데, 이는 전형적인 Repository Pattern 구현을 위한 구조로 보입니다. 인터페이스는 Domain에 위치하고 구현체는 Data에 위치하여 의존성 역전이 실제로 잘 이루어지고 있는지 코드 수준에서 잘 확인되면 좋을 것 같습니다.
make setup부터 make feature까지 워크플로우를 자동화한 온보딩이 좋습니다!!
현재는 테스트 타겟정의가 보이지 않습니다. RIBs 아키텍처의 큰 장점 중 하나가 테스트 용이성인 만큼, 모듈 생성 시 테스트 타겟과 기본적인 테스트 클래스도 함께 생성되도록 템플릿을 추후에 확장하는 것도 고려해볼 수 있을 것 같습니다.
|
아차차 결론적으로 머지해도 될 것 같습니다 !우선 제 환경에서도 빌드가 되는 것 확인했어요! |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
🔗 연결된 이슈
📄 작업 내용
🧰 모듈 구조
전체적인 구조는 Feature - Data/Domain - Core - Shared 계층으로 분리되어 있으며, 각 레이어의 역할은 다음과 같습니다.
1.App Layer (Blue)
App: 프로젝트의 엔트리 포인트입니다. RootFeature 및 Data 모듈에 의존하며 앱의 실행 환경을 설정합니다.
2.Feature Layer (Red/Orange)
사용자 인터페이스와 비즈니스 로직이 포함된 계층입니다.
RootFeature: 앱의 메인 진입 화면을 담당하며 HomeFeature로 연결됩니다.
HomeFeature: 실제 서비스의 주요 기능을 담당합니다.
BaseFeatureDependency: 모든 Feature 모듈이 공통으로 사용하는 의존성(DSKit, Domain 등)을 모아둔 중간 레이어입니다. 불필요한 중복 의존성 작성을 방지합니다.
3. Data & Domain Layer (Red/Orange)
비즈니스 규칙과 데이터 통신을 담당하는 계층입니다.
Data: Domain 및 Networks에 의존하며, 외부 데이터 소스로부터 데이터를 가져와 앱 내부 모델로 변환합니다.
Domain: 앱의 순수 비즈니스 로직(Entity, UseCase)이 위치합니다.
Networks: Moya 기반의 네트워크 통신 로직을 담당하며 Core 레이어에 의존합니다.
4.Core & Shared Layer (Yellow)
앱 전반에서 공통으로 사용되는 유틸리티와 외부 라이브러리 계층입니다.
DSKit: 디자인 시스템 모듈입니다. UI 컴포넌트, 컬러, 폰트 등을 관리합니다.
Core: 로그, 확장 함수 등 앱 전역에서 쓰이는 유틸리티를 포함합니다.
ThirdPartyLibs: 프로젝트에서 사용하는 외부 라이브러리들을 한곳에서 관리하여 의존성 관리를 단순화합니다.
5.Third Party Dependencies
프로젝트 성능과 개발 생산성을 위해 사용된 주요 라이브러리 관계입니다.
Reactive Stack: RxSwift, RxCocoa, RxRelay 등을 중심으로 반응형 프로그래밍을 지원합니다.
Network Stack: Moya를 주축으로 Alamofire, CFNetwork가 하위 레이어에서 동작합니다.
UI & Tool: SnapKit(Layout), Then(Syntactic Sugar), Kingfisher(Image) 등이 포함되어 있습니다.
의존성 설계 원칙
단방향 의존성: 상위 레이어에서 하위 레이어로만 의존성이 흐르도록 하여 순환 참조를 방지했습니다.
라이브러리 격리: ThirdPartyLibs 모듈을 두어 외부 라이브러리(RxSwift, Moya, SnapKit 등)의 변경이 개별 모듈에 직접적인 영향을 주지 않도록 설계했습니다.
🛠️ Makefile
모든 팀원이 동일한 환경에서 개발하고, 반복적인 작업을 클릭 한 번(또는 명령어 한 줄)으로 해결할 수 있도록 Makefile을 도입했습니다.
주요 명령어
✍🏻 make feature 사용후
1. Dependency 설정
Plugins/DependencyPlugin/ProjectDescriptionHelpers/Dependency+Project.swift파일로 이동위와 같이 TargetDependency를 추가합니다.
2. RootFeature 의존성 추가
Projects/Features/RootFeature/Project.swift위와 같이 RootFeature에 새로 생성한 Feature의 의존성을 추가해줍니다.
🧑🏻💻 Tuist 명령어 edit vs generate
1. tuist edit (설정 변경 시)
역할: 프로젝트의 설계도인 Project.swift, Workspace.swift 등을 수정하기 위한 임시 Xcode 프로젝트를 생성합니다.
새로운 타겟(Target)이나 모듈을 수동으로 추가할 때
외부 라이브러리 의존성을 변경할 때
빌드 세팅(Build Settings)이나 스키마(Schema) 정의를 수정할 때
특징: 이 명령어로 열린 Xcode에서 소스 코드(.swift)를 수정하는 것이 아니라, 프로젝트 구조 설정만 수정합니다. 수정 후 저장하면 실제 설계도 파일에 반영됩니다.
2. tuist generate (코드 작성 시)
역할: Project.swift 설계도를 바탕으로 실제 개발용 .xcodeproj와 .xcworkspace를 생성합니다.
새로운 소스 파일이나 리소스(이미지 등)를 폴더에 추가했을 때
다른 브랜치에서 git pull을 받은 직후
tuist edit으로 설정을 변경한 후 실제 프로젝트에 적용하고 싶을 때
특징: 우리 프로젝트는 make generate 명령어를 통해 tuist install과 함께 실행되도록 자동화되어 있습니다.
👀 기타 더 이야기해볼 점
make setup
현재 make setup를 통해 세팅하는 부분의 경우 테스트를 못한 상태입니다.
해당 pr이 올라간 뒤 테스트 진행해보겠습니다.
또한 xcconfigs 폴더와 fastlane/.env.default 파일의 경우 private 레포를 통해 자동으로 다운 받는 로직을 추후에 도입할 예정으로
현재는 제가 따로 파일 보내드리겠습니다.
SwiftLint
SwiftLint의 경우 임시로 작성해서 넣어뒀고 회의 후에 수정하면 될 거 같습니다.
fastlane match
private 레포에 초대하고 기기 등록 진행해야됩니다.