[디자인패턴 변환 코드 리팩토링 - 최종 선택 패턴과 그 이유]

 

가장 중요한점. 기존의 MVC패턴을 "점진적"으로 변환해야 한다 !!

 

[선택 과정]

1) 각 아키텍쳐 별 장단점 파악 (Clean Architecture, RIBs, VIPER)

2) 기존의 MVC패턴에서 변환하기에 적합한 패턴이어야 한다

>> 최종으로 VIPER를 선택함

VIPER (최종선택)	1. 화면단위 모듈화 화면단위로 분리하여 리팩토링할 수 있기 때문에 기존 코드를 크게 수정하지 않고 새로운 구조 도입 가능 2. 점진적 변환 기존의 ViewController를 VIPER의 View로 변환하고, 비즈니스 로직을 Interactor로 이동시키는 방식으로 점진적이고 부분적인 전환 가능  => 전체적인 구조를 바꿀필요 없음
RIBs	1. RIBs는 기능 단위의 독립성을 강조하여 각 RIB이 독립적인 모듈로 작동 (부모RIB-자식RIB간 독립성)  - 기능의 분리가 잘 된다는 장점이 있지만  - 모든 기능을 RIB 단위로 재구성해야 하며, 의존성관리를 위해 모든 모듈이 명확한 부모-자식 관계로 정리되어야 함 => 점진적 변환과는 거리가 멀다
Clean Architecture	1. 앱 전체 구조에 초점: 의존성 규칙(Dependency Rule)에 따라 내부 계층이 외부 계층에 의존할 수 없으며, 데이터 흐름이 안쪽에서 바깥쪽으로만 이루어져야 합니다. 이는 기존의 MVC 패턴에서 ViewController가 직접 Model과 상호작용하며 비즈니스 로직을 포함하는 방식과 충돌 2. MVC 패턴에서는 비즈니스 로직이 ViewController에 밀접하게 포함되는 경우가 많습니다. 클린 아키텍처로 전환하려면, 이러한 비즈니스 로직을 UI로부터 분리하여 독립적인 Use Case로 이동시켜야 합니다.

 

 * RIBs가 각 RIB이 독립적으로 동작하여 기능의 분리를 잘 유지한다는 측면에서 당사 프로젝트 운영 취지와

가장 부합하지만,  기존 프로젝트를 점진적으로 변환하는데는 큰 작업이 소요됨.

 

 *** RIBs아키텍쳐가 강력한 영향을 발휘할때는 현재와 같은 유지보수성 향상을 위한 MVC에서의 변환이 아니라,

   "대규모 프로젝트, 고도의 모듈화 필요성, 여러 팀 간의 독립적 개발 요구"와 같은 상황임

- RIBs는 모듈 간 의존성을 철저히 관리하여, 특정 모듈의 변경이 다른 모듈에 영향을 주지 않음

 => 독립적으로 개발, 테스트, 배포 가능하며  여러 팀이 동시에 개발을 진행할 때 충돌을 최소화할 수 있음

 

***  운영업무 편의성 향상을 위한 측면에서는 "유지보수 용이성, 각 역할 간 명확한 책임분리" 두 가지가 중요하다고 생각함.

이는 VIPER로 충분히 가능하다.

물론 RIBs도 해당 장점이 있으나, 이를 위해 도입하기에는 기존 프로젝트를 점진적으로 변환하는데 큰 작업이 소요됨.

- 특정 기능의 변경이나 버그 수정이 다른 기능에 영향X 이는 복잡한 시스템에서 유지보수를 단순화하고 리스크를 줄일 수 있음

- 구성 요소의 명확한 역할: View, Interactor, Presenter, Router 등 각 구성 요소가 명확한 역할을 가져 비즈니스 로직과 UI 로직이 철저히 분리됨

 

 

---

 

 

[최종선택 모델]

VIPER의 Interactor에 Clean Architecture의 UserCase 개념을 도입하기로 결정.

 

* 결론적인 이유)

화면단위로 분리된 아키텍쳐는 유지하되,  범용적으로 사용되는 핵심 비즈니스 로직은 분리하고싶음.

=> Clean Architecture의 재사용성과 VIPER의 화면 단위 관리 장점을 결합함

 

* 당사 소스코드 구조

투자자정보 확인서 징구 로직, 이체 로직 등 공통적인 핵심로직이 여러 화면에서 공통적으로 사용되나,

현재는 이를 각각 화면에서 모두 구현하고 있음.

 - 이런 로직에서 IO변경 요청이나 로직 변경 요청이 오면 매 화면마다 동일하게 수정해줘야함. 영향도도 크고 누락될 가능성 존재.

 ==>  화면과 무관하게 공통적으로 사용되는 주요 로직은 UseCase에 분리하고,   VIPER의 Interactor로 Use Case에 접근하여 여러 화면에서 사용하는 구조로 변환하고자 함.

 

 

* 결과)

1. 재사용성 향상:  Use Case는 화면(View)와 독립적이기 때문에 여러 화면에서 각 Interator로 접근하여 재사용가능

2. 유지보수 용이: 비즈니스 로직이 변경되더라도 Use Case만 수정하면 됨 (Interactor는 해당로직을 단순히 호출하는 역할만 담당)

 

 

비고)

	Clean Architecture - Use Case	VIPER - Interactor
목적	특정 비즈니스 로직이나 애플리케이션의 한 가지 작업(Use Case)을 수행하는 데 초점을 맞춤	화면(View)과 관련된 비즈니스 로직을 수행하며, 해당 화면의 기능을 담당
범위	전체 애플리케이션에서 공유 및 재사용될 수 있는 범용적인 비즈니스 로직을 담음	특정 화면의 요구 사항에 맞는 비즈니스 로직을 담당하며, 주로 그 화면에 국한됨
책임	애플리케이션의 고수준 비즈니스 로직을 정의하며, 여러 객체 및 서비스와 상호작용함	Presenter로부터 전달받은 요청을 처리하며, 데이터와의 통신 및 비즈니스 로직 수행에 집중