Architecture_401_CleanArchitecture.md

Clean Architecture(클린 아키텍쳐)

클린아키텍쳐는 Robert C Martin(aka Uncle Bob)이 제안한 아키텍쳐의 형태이다.

첫번째 핵심에 대하여

그동안 경험한 패턴들

• MVC
• MVP
• MVVM
  • MVVM + C
• VIPER

이 패턴들을 선택하는 기준들은 뭘까?

• 프로젝트의 규모
• 프로젝트의 성향
• 가독성
• 유지보수
• 비용(인건비)

유지보수

• 코드 읽기
• 코드 이해
• 코드 수정 / 추가

아키텍쳐는 "있어야 할 곳에 두는 약속"

코드에 대한 약속이 되어있다면, 그만큼 유지보수가 쉬워진다.

이를 위해서 용도별로 계층을 나누는 것

회사에서 특정한 사업 아이템을 가지고 서비스를 진행한다고 했을떄,

완전히 사업의 성향이 바뀌지 않는 한, 핵심 서비스 자체는 동일할 것이다.

그렇다면 시간에 따라 바뀌는 것은??

그 사업의 중심에 따른 부가적인 서비스들이 생겨날 것이다.

그 구조를 일단 3가지로 나눠보자.

• 프레젠테이션 계층
  • View
  • Presenter
• 도메인 계층
  • Entity : 실질적인 모델
  • Use Case : 비즈니스 로직이 들어 있는 영역
• 데이터 계층
  • Repository : 유즈 케이스가 필요로 하는 데이터의 저장이나 수정하는 기능을 제공하는 영역, 로컬DB와 네트워크 통신함.
  • Data Source : 실제 데이터의 입출력을 담당

두번째 문제 : 의존성에 대하여

예를 들어 UITextfield 검색, 이미지를 콜렉션뷰에 보여주는 앱

ViewController 하나로 할 수 있다.

문제는..

• 이미지 API 교체
• 네트워크 라이브러리 교체
• UIKit <-> SwiftUI
• 새로운 기능추가
• 해당 로직을 프레임워크화 할때

연쇄적으로 뜯어 고치는 상황이 발생

자주 바꿀 곳은 보수하기 좋게,

도메인영역은 항상성을 유지할 것

중간에 원하는 형태로 변환하는 부분을 주어서 의존성을 떨어뜨릴 것

프로토콜을 이용해서 필요한 정보 맞으면 얼마든지 바꿀 수 있도록 구현

-> 연달아서 수정해야하는 불상사를 없앨 수 있다.

클린코드를 보면 여러가지 패턴들이 등장

그중 영향을 많이 준 아키텍쳐

• 헥사고날 아키텍쳐
• BCE: Boundary-Control-Entity
• DCI: Data, Context and Interaction

여러 아키텍쳐를 하나로 통합 시도..

• 공통의 목표로는 관심사의 분리
• 공통의 핵심규칙 : 의존성의 방향은 안쪽, 고수준을 향한다.

• 핵심 1 : 중요도에 따라 계층을 나눈다.
• 핵심 2 : 의존성의 방향은 항상 안쪽, 고수준을 향한다.
  • 다형성을 이용하여 의존성은 어디서든 역전 가능

애매함

엉클밥....

알아서, 적당히, 조심히

나름의 기준

• 필요한 시스템을 만들고 유지보수 하는데 투입되는 인력을 최소화 할 수 있나
• 소스코드의 의존성이 안쪽으로, 고수준을 향하나
• 세부사항이 변경돼도 도메인에 변경이 업을 것인가
• 테스트하기 쉬운가
• 각각의 아키텍처들의 원칙을 잘지키는지?

어떻게 사용할 것인가

• MVC
• MVP
• MVVM
• VIPER

등등을 용도에 맞게 구현하고

프로젝트의 확장에 따라 변경하는 것처럼

기본기를 먼저 잘 익혀볼것..