https://github.com/protocorn93/iOS-Architecture

Overview

iOS Architecture Patterns 글을 참조하여 콘이 작성한 글을 그대로 작성한 것이다.

Architecture

구조를 생각하지 않고 프로그램을 작성한다고 프로그램이 돌아가지 않는 것은 아니다. 하지만 이런 프로그램은 가독성이 떨어지고 유지 보수 비용이 많이 든다. 또한 테스트 단계에서 테스트 자체가 불가능할 수 있다.

단순히 모듈(클래스)을 역할별로 나누어 관리하는 것이 아키텍쳐는 아니다. 특정 기준으로 역할을 정의하며 역할별로 나누어진 모듈간의 관계를 유기적으로 형성한 것이 아키텍쳐라 할 수 있다.

좋은 아키텍쳐은 기준과 특징

• Balanced Distribution : 객체들의 역할이 확실하며 이런 역할들이 균형있게 분배되어 있는지 각 모듈이 독립적인지를 확인한다. ****
  • 확고한 역할의 분배는 프로그램의 복잡도를 낮출수 있다.
  • SOLID 원칙 중 단일 책임 원칙(SRP - Single Responsiblity)에 기반한다
    • 하나의 객체는 하나의 역할만을 가져야 한다는 원칙이다
  • 모듈의 독립성이 떨어지면 테스트를 진행하는데 어려움이 있다.
• Testability : 테스트를 진행할 수 있는지 확인한다.
  • 테스팅 과정은 런타임 중 발생하는 이슈를 사전에 찾아내기 위해 필요한 단계이다.
  • 테스팅에 있어서 그 자체가 문제라기보단 테스팅을 진행하려는 아키텍쳐가 문제가 되는 경우가 더 많다.
• Easy of USE : 사용하기 쉬운지를 확인한다
  • 사용하기 쉬운지에 따라 개발 속도는 비례한다.
• Unidirectional Data Flow : 단방향성의 데이터 흐름인지 확인한다
  • 데이터의 흐름이 단순할수록 코드를 이해하기 쉬우며 디버깅에 용이하다.
    • 여러 객체들을 오가는 데이터는 옳지 않다.
  • Shared Resource의 사용도 기피해야한다. 에러가 발생하면 원인을 찾기 힘들 수 있다.

프로젝트의 성격에 맞게 선택적으로 도입해야 한다.

Distribution

• Model: 프로그램에서 사용되는 데이터의 조작이 일어나고 이를 담당하는 부분이다.
• View: 시각적인 부분(UI)에 해당한다. (iOS환경에서 UI 접두어가 붙은 모든 것들이 이에 해당한다)
• Controller / Presenter / ViewModel : Model과 View 사이의 중재자로 일반적으로 View를 통해 발생한 사용자의 액션을 다루며 필요시 이에 따른 Model에 값의 조정을 요청하며 Model 값의 변화에 맞게 View를 갱신하는 역할을 말한다.

위와 같이 Distribution을 기준을 정해 나누어 진행한다면 재사용성이 증가하며 독립적으로 테스팅할 수 있게 된다.