프로젝트에 클린 아키텍처를 적용하기 전에, 그 개념을 확실히 이해하고자 간단한 예제를 통해 클린 아키텍처를 설계해보고자 한다. 도메인 계층✔️ Entity유저 리스트를 보여주는 것이 주요 서비스이기 때문에 핵심 데이터는 유저이다. 그래서 Entity에는 유저 정보가 담겨있다. ✔️ UserUseCaseProtocolUseCase는 비즈니스 로직이다. 여기서 비즈니스 로직은 유저의 정보를 받아오는 것이다. 이 로직을 처리하기 위해서는 Data 계층에서 데이터를 가져와야하는데, Domain 계층이 Data 계층을 의존하게 될 경우 의존성 규칙을 위배하게 되는 것이므로, 직접 참조하지 않고 의존성 역전을 이용하여 참조한다. ✅ 의존성 역전Repository Interface를 구현해서 UseCase가 이를..
클린 아키텍처?클린아키텍처란? 클린 아키텍처는 소프트웨어 설계 원칙으로, 로버트 C. 마틴이 제안한 개념이다. 클린 아키텍처의 주요 목표는 아래와 같다. 1. 프레임워크 독립성 : 시스템이 특정 프레임워크에 종속되지 않도록 한다.➡️ 처음에는 UIKit을 사용했지만, SwiftUI로 전환해야 할 상황이 생겼다. 비즈니스 로직을 UIKit과 독립적인 별도의 모듈로 구현한다. 이렇게 하면 나중에 SwiftUI로 전환하고자 할 때, UI레이어만 변경하면 되고 핵심 비즈니스 로직은 그대로 사용할 수 있다. 2. 테스트 용이성 : 비즈니스 로직을 외부 요소 없이 테스트할 수 있게 한다.➡️ '장바구니에 책 추가하기' 기능을 구현한다고 가정하자. 이 기능을 순수한 비즈니스 로직으로 구현하여, 필요한 외부 의존성(데..
전달 받은 최종본 디자인을 가지고 개발을 시작했지만, 애니메이션 이슈로 인해 전면 수정이 필요했고, 이후에도 회의를 거치며 디자인이 계속 변경되어 처음부터 다시 개발을 하게 됐다. 디자이너와의 첫 협업이었던 만큼, 팀 전체가 효과적인 협업 프로세스를 구축하는데 어려움을 느끼고 있다. 다시 처음부터 원래 디자인이었다. 각 페이지를 뷰컨트롤러로 만들고, 네비게이션에 Push하는 방식으로 구현했기 때문에, 프로그레스바 애니메이션이 작동하지 않고 부자연스럽게 화면 전환이 일어났다. 디자이너와 상의를 했고, 부자연스러운 애니메이션과 복잡한 파일구조 등 여러 이유로 하나의 뷰컨트롤러에서 여러 개의 뷰를 관리하도록 재개발했다. 이를 통해 원하는 애니메이션이 작동 했지만, 우리가 원하는 로직을 구현하는데 어려움이 ..
오랜 기획 끝에 드디어 본격적인 개발을 시작했다. 처음에는 3주면 충분할 거라 생각했던 기획 단계가 예상을 훌쩍 뛰어넘어 길어졌다. 기획 과정에서 우리 팀은 수많은 변화와 도전을 겪었다. 디자인은 계속해서 수정되었고, 앱의 기능도 여러 차례 변경을 거쳤다. 처음에는 이러한 변화와 지연이 답답하게 느껴졌지만, 돌이켜보니 이 모든 과정이 정말 값진 경험이었다. 기획은 거의 마무리 단계에 이르렀지만, 디자인 작업이 아직 완전히 끝나지 않아 개발을 미루고 있었다. 그러던 중 디자이너로부터 완성 페이지를 받게 되었고, 이를 바탕으로 UI 개발을 시작하게 되었다. 코디네이터 도입 이번 프로젝트에서는 코디네이터 패턴을 도입했다. 새로운 아키텍처 패턴을 학습하고 실제 프로젝트에 적용해 보기 위함도 있지만, 우리 앱이..
