클린 아키텍쳐 , 레이어드 아키텍쳐

레이어드 아키텍처

각각 역할에 맞게 계층을 나눈것이다. 

UI(Presentation) → Application → Domain → Infra(Data)

위와같이 계층이 나누게되며 화살표 방향대로 의존성 방향이다.

 

간단히 각 계층은 이런 역할들을 담당한다.

UI

웹통신 프레임워크, 인터페이스, 입출력 등 외부와의 통신

Application

앱의 주요기능(비즈니스 로직) ,트랜잭션의 시작과끝

Domain

도메인 문제를 담담 (모델)

Infra

DB와 연결 , 앱외적인 인프라와의 어댑터역할

 

 

레이어드 아키텍쳐의 단점은 DB가 설계의 중점이된다는것이다.

따라서 설계에서 DB 설계를 먼저 하게된다.

DB설계를 먼저 하게되면 객체의 “액션"이 먼저가 아닌

“상태" 중심적인 설계를 하게된다.

이는 객체지향에 벗어나는 코드를 많이 쓰게만든다.

 

 

 

이후 에 DB를 부품마냥 다른거로 바꿀수있도록 보는 아키텍쳐들이 주목을 받았다.

이런 아키텍쳐들은 애플리케이션을 중심으로 설계한다.

대표적으로 클린 아키텍쳐가 있다.

 

 

클린아키텍쳐

클린아키텍쳐는 계층의 흐름이 이렇게 된다.

DB, UI(Framework) → Controller,Presenter(Interface adapter) → Usecase → Entity

내부로(Entity) 갈수록 잘 안변하며 외부로부터 영향을 받지 않는다.

즉 DB가 바뀌어도 UI가 바뀌어도 쉽게 수정이 가능하다.

 

그리고 내부로 갈수록 (Entity Usecase)고수준이라 말한다.(외부는 저수준, 구체적)

이렇게 의존성 방향도 저수준에서 고수준으로 향해야한다.

 

하지만 예를 들어 “유저 생성" usecase를 만들떄

이 usecase 는 DB 에 연동된 리포지토리를 이용한다. (저장하기 위해)

Usecase(고수준) 이고 리포지토리는 Framework영역이다.(저수준)

이는 의존성 방향을 위반한다.

 

그래서 저수준인 리포지토리를 추상화한 리포지토리 인터페이스를 만들고 그 인터페이스를 사용한다.

리포지토리 인터페이스 는 추상화된 개념이라 고수준이라 한다

register(AppSettingUsecase.self) { resolver in
      guard let repository = resolver.resolve(AppSettingRepository.self) as? AppSettingRepositoryImpl else { fatalError("register AppSettingUsecase error")}
       return AppSettingUsecaseImpl(repository: repository)
  }

실제 서비스에서 의존성 주입 부분을 가져왔다.

해당 코드는 Appdelegate(앱이 시작될떄 실행) 에서 실행된다.

AppSettingUsecaseImpl (고수준) 은

AppSettingRepositoryImpl (저수준) 을 필요로 하고있다.

하지만 AppSettingRepositoryImpl(저수준)의 인터페이스인 AppSettingRepository(고수준) 을 가져와서

AppSettingUsecaseImpl을 생성할때 넣어줬다.