이전 1 2 3 편에 걸쳐 레이어별 책임과 경계를 정하는 과정을 이야기했다면, 이제는 실제로 이것들을 어떻게 물리적 모듈로 분리할 것인가에 대한 고민이 시작되었습니다. 프로젝트를 처음 설계 할때 클린 아키텍처를 통해 레이어의 완전한 분리를 목표로 삼았고, 클린 아키텍처의 레이어를 기반으로 물리적 모듈을 나누고자 Tuist를 사용하여 모듈을 분리했습니다. 처음 나눈 구조는 이와같습니다.NoWeekend/├── App/ # 🎯 최상위 앱 레이어├── Features/ # ✨ 각 기능별 모듈들│ ├── Calendar/│ ├── Home/│ └── Profile/│ ├── Common/ ..

1편과 2편에서 클린 아키텍처의 이론적 배경과 구현 과정에 대해 이야기했다면 3편에서는 제가 어떻게 구현했는지, 어떤 고민들을 했었는지에 대한 트러블 슈팅 정리본입니다.폴더 구조는 어떻게 설계할 것인가?Entity와 Repository는 각각 어느 위치에 배치해야 할까?각 레이어의 경계를 어디까지 설정하는 것이 적절할까?등과같은 고민들, 그리고 클린아키텍처 기반으로 물리적 모듈설정을 Tuist로 세팅하였는데 관련된 트러블 슈팅까지 정리하는 정리본입니다. 전체코드는https://github.com/mash-up-kr/NoWeekend-iOS GitHub - mash-up-kr/NoWeekend-iOS: 금토일빼고 다돼! (🚧🚧 WIP 🚧🚧)금토일빼고 다돼! (🚧🚧 WIP 🚧🚧). Contri..

클린 아키텍처 레이어 구조1편에서 기본적으로 클린 아키텍처가 왜 필요했는지 말했다면, 이제 실제 프로젝트에서 어떻게 구현해야 하는지 알아보겠습니다.저도 처음에는 동심원 구조는 이해를 했는데 그래서 실제 코드로 어떻게 옮겨야 하지? 라는 고민이 제일 컸었습니다. 해당 고민을 천천히 나눠볼게요.클린 아키텍처를 iOS 프로젝트에 적용할 때는 보통 4개의 레이어로 구성합니다┌─────────────────────────────────────────────┐│ Presentation Layer │ ← SwiftUI Views, ViewModels├─────────────────────────────────────────────┤│ Domain..

iOS 개발을 시작하면서 "MVVM이 좋다더라", "클린 아키텍처를 써야 한다더라" 하는 이야기들을 자주 들었고 다양한 블로그나 깃허브 레포에 적혀져 있는 글들을 많이 보았었습니다. 사실 이전까지는 클린아키텍쳐를 써야하는 당위성에 대해서 잘 몰랏기도 했고 없어도 크게 불편한부분이 없었습니다. 특히나 클린아키텍쳐를 사용하여 구현한 코드들을 보더라도"깔끔하긴 한데, 그래서 이게 뭐?”라는 의문이 들었었습니다.하지만 이번에 동아리에서 프로젝트를 하면서 좀더 깊게 공부를 해보았고 공부했던 내용들을 적어보고자 합니다.내가 참고한 레포구현을 위한 구현개발을 하다보면 일정이 부족해져서 "일단 돌아가게만 만들자"라는 생각으로 코드를 작성하게 되는 경우가 꽤나 많습니다 (이번 동아리 프로젝트도 그랬던)처음에는 빠르게 원..

이전 블로그에 이어서 쓸래말래 프로젝트에 사용된 Coordinator 사용기를 남겨보고자 한다. 전체코드는 여기에! Coordinator 패턴이란?Coordinator 패턴은 네비게이션 로직을 View와 분리하여 관리하는 패턴입니다.UIKit에서는 UINavigationController를 통해 네비게이션을 처리했고navigationController?.pushViewController(detailVC, animated: true)navigationController?.present(modalVC, animated: true)`SwiftUI에서는 NavigationStack과 바인딩을 활용해서 네비게이션을 처리했었습니다.NavigationStack(path: $path) { ContentView()..

최근 프로젝트에서 사용했던 DI 방법을 트러블 슈팅겸 적어보고자 한다.전체코드는https://github.com/mash-up-kr/NoWeekend-iOS GitHub - mash-up-kr/NoWeekend-iOS: 금토일빼고 다돼! (🚧🚧 WIP 🚧🚧)금토일빼고 다돼! (🚧🚧 WIP 🚧🚧). Contribute to mash-up-kr/NoWeekend-iOS development by creating an account on GitHub.github.com에서 확인할 수 있다. 1. DI?의존성 주입(Dependency Injection, DI)은 객체지향 프로그래밍에서 객체 간의 의존성을 효율적으로 관리하는 설계 패턴입니다.의존성이란 무엇인가?의존성(Dependency)은 한 객체..

weak letSwift 6.2에서 도입된 weak let이 사용 가능하도록 문법이 개선되었습니다.Swift의 메모리 관리와 동시성 모델이 만나면서 발생한 근본적인 문제를 해결하기 위해 문법을 수정한것 같아요.weak 참조 톺아보기Swift는 ARC를 기반으로 메모리를 관리하는데 객체를 참조할 때마다 참조 카운트 증가, 참조가 해제되면 감소, 카운트가 0이 되면 객체는 메모리에서 해제됩니다.하지만 이 방식으로 메모리 관리를 하다보면 순환 참조(retain cycle)가 발생합니다.class Person { var pet: Dog?}class Dog { var owner: Person? // 강한 참조로 인한 순환 참조}let john = Person()let buddy = Dog()john...

팩토리 패턴팩토리 메소드 패턴이란?팩토리 메소드 패턴은 객체를 만드는 방법을 인터페이스로 정의하고, 실제로 어떤 객체를 만들지는 서브 클래스가 결정하도록 하는 패턴입니다. 쉽게 말해, "객체 생성을 전담하는 공장"을 만드는 느낌s왜 팩토리 패턴을 사용해야 할까?객체 지향 프로그래밍의 원칙 중 하나는 OCP(Open-Closed Principle) 입니다. 즉, 확장에는 열려있고 수정에는 닫혀야 한다 는 건데,,, 중요한 건 "수정에 닫혀있다" 는 부분입니다.기존 코드를 건드리지 않고도 새로운 기능을 추가할 수 있어야 한다는 말인데, 변경될 가능성이 높은 부분과 안정적인 부분을 분리하는 것이 중요하다는 겁니다객체가 생성되는 부분은 변경될 가능성이 높습니다. 생성자가 바뀌거나, 새로운 타입의 객체가 추가되거..

SwiftUI를 도입하고나서, 기존 MVVM이 맞다 틀리다,, 수많은 논쟁이 있는데요,,https://qiita.com/karamage/items/8a9c76caff187d3eb838 「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由 - Qiita※2022/04/23 追記 本記事の続編として、以下の記事を書きましたので、合わせて御覧ください。 仕事でSwiftUIでTCAを使ってみて、かなり知見がたまったので、その解説です。 MVVMからTCAへの移行qiita.com https://www.reddit.com/r/swift/comments/m60pv7/is_mvvm_an_antipattern_in_swiftui/ From the swift community on Reddit: Is MVVM an anti-patt..