Clean Architecture
'추상화 개념'으로써 관심사를 분리시키고 의존도를 낮추는 것에 목적을 둔 아키텍처이다.
클린 아키텍쳐를 사용하는 이유
클린 아키텍쳐를 사용함으로써 그런 일이 발생하더라도 베이스 파일은 그대로 유지하고
필요한 부분만 바꿀 수 있어도 프로젝트 상에 문제가 되지 않게 진행하기 위해
클린 아키텍쳐를 사용하는 이유라고 생각한다.
- 소스코드를 변경할때 안정성 ⬆️
- 인프라 계층에 테스트도 가능
- 코드 가독성 ⬆️
- 유지보수성을 향상 ⬆️
사용했을때의 단점
프로젝트가 너무 급한 상황일때 아키텍쳐를 전부 나눠서 작업하는게 제약인 상황에서 천천히 하나하나 설계 하기 어려워 클린아키텍쳐 방식을 지키기 어렵다.
클린아키텍쳐시 지켜야할 점
- 가운데로 길수록 잘 변하지 않으며, 변화가 미치는 영향은 피할 수 없다.
- 밖으로 갈수록 자주 변하며, 변화가 미치는 범위가 작아야 한다.
회사에서 클린 아키텍쳐를 채택한 이유..?
클린아키텍쳐를 공부하면 할수록 안드로이드 분야에서 자주 쓰이는 설계 방법이라고 자주 보인다. 첫 설계를 맡으셨던 분이 안드로이드 개발자 출신이어서 클린아키텍쳐를 쉽게 채택하지 않았을까 하는 이유도 생각해봤다.
그리고 회사에서 적용한 방법이 완전한 클린아키텍쳐 형식도 아니고 구조만 클린아키텍쳐와 맞추려고 했단 사실도 뒤늦게 알았다.
확실히 클린아키텍쳐를 도입 해본 후에
의존성이 분리되어야하는 이유에 대해서도 느끼게 되었고,
비즈니스 코드를 이해하기 쉬웠다.
회사에서 사용했던 클린아키텍쳐 방식이 처음에 이해할땐, repository 라는 개념이 너무 생소하고, index 파일과, 구현체 파일도 너무 헷갈렸는데
한번 하고 나서는 물론 코드의 양과 신경써야할 부분이 많은 것도 사실이지만, 코드가 깔끔해지고, 의존성이 분리되서 코드를 고치기 쉽다라는 점이 확실하게 좋았던 것 같다고 느낀다.
회사에서 클린아키텍쳐에서 의존성을 분리한 방법
- index, 구현체
- class
- injector
DI
디자인 패턴
기존 환경 내에서 반복적으로 일어나는 문제들을 어떻게 풀어나갈 것인가에 대한 일종의 솔루션이다.
MVC
구조
- Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리
- View : 사용자에서 보여지는 UI
- Controller : 사용자의 입력(Action)을 받고 처리
동작원리
- 사용자의 Action Controller에 진입한다.
- Controller는 사용자의 Action를 확인하고, Model을 업데이트한다.
- Controller는 Model을 나타내줄 View를 선택한다.
- View는 Model을 이용하여 화면을 그린다.
특징
- Controller는 여러개의 View를 선택할 수 있는 1:n 구조이다.
- Controller는 View를 선택할 뿐 직접 업데이트 하지 않는다.
(View는 Controller를 알지 못합니다.)
장단점
- 장점 : 널리 사용되고 있는 패턴이라는 점에 걸맞게 가장 단순하다. (가장 많이 사용)
- 단점 : View와 Model 사이의 의존성이 높다. 어플리케이션이 커질 수록 복잡하지고 유지보수가 어렵게 만들 수 있다.
MVP
구조
- Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리
- View : 사용자에서 보여지는 UI
- Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달
(View와 Model을 붙여주는 접착제 역할)
동작원리
- 사용자의 Action들은 View를 통해 진입
- View는 데이터를 Presenter에 요청
- Presenter는 Model에게 데이터를 요청
- Model은 Presenter에서 요청받은 데이터를 응답
- Presenter는 View에게 데이터를 응답
- View는 Presenter가 응답한 데이터를 이용하여 화면을 그린다.
특징
- Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할을 합니다.
- Presenter와 View는 1:1 관계입니다.
장단점
- 장점 : View와 Model의 의존성이 없다는 것입니다.
MVP 패턴은 MVC 패턴의 단점이었던 View와 Model의 의존성을 해결 - 단점 : View와 Presenter 사이의 의존성이 높아짐. 어플리케이션이 복잡해 질 수록 View와 Presenter 사이의 의존성이 강해지는 단점이 있습니다.
MVVM
구조
- Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리
- View : 사용자에서 보여지는 UI
- View Model : View를 표현하기 위해 만든 View를 위한 Model입니다.
View를 나타내기 위한 데이터 처리를 하는 부분입니다.
동작원리
- 사용자의 Action들은 View를 통해 진입
- View에 Action이 들어오면, Command 패턴으로 View Model에 Action을 전달
- View Model은 Model에게 데이터를 요청
- Model은 View Model에게 요청받은 데이터를 응답
- View Model은 응답 받은 데이터를 가공하여 저장
- View는 View Model과 Data Binding하여 화면을 그린다.
특징
- Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현되었습니다.
- Command 패턴과 Data Binding을 이용하여 View와 View Model 사이의 의존성을 없앴다.
장단점
- 장점 : MVVM 패턴은 View와 Model 사이의 의존성이 없다.
- 장점 : Command 패턴과 Data Binding을 사용하여 View와 View Model 사이의 의존성 또한 없앤 디자인패턴이다.
- 각각의 부분은 독립적이기 때문에 모듈화 하여 개발할 수 있습니다.
- 단점 : MVVM 패턴의 단점은 View Model의 설계가 쉽지 않다는 점
