프로젝트에 클린 아키텍처를 적용하기 전에, 그 개념을 확실히 이해하고자 간단한 예제를 통해 클린 아키텍처를 설계해보고자 한다.
도메인 계층
✔️ Entity
유저 리스트를 보여주는 것이 주요 서비스이기 때문에 핵심 데이터는 유저이다. 그래서 Entity에는 유저 정보가 담겨있다.
✔️ UserUseCaseProtocol
UseCase는 비즈니스 로직이다. 여기서 비즈니스 로직은 유저의 정보를 받아오는 것이다. 이 로직을 처리하기 위해서는 Data 계층에서 데이터를 가져와야하는데, Domain 계층이 Data 계층을 의존하게 될 경우 의존성 규칙을 위배하게 되는 것이므로, 직접 참조하지 않고 의존성 역전을 이용하여 참조한다.
✅ 의존성 역전
Repository Interface를 구현해서 UseCase가 이를 참조하게 하여 의존성 역전을 구현한다.
❓의존성?, 의존한다?
class Car {
let engine: Engine
init(engine: Engine) {
self.engine = engine
}
func start() {
engine.turnOn()
}
}
class Engine {
func turnOn() {
print("Engine started")
}
}
let myEngine = Engine()
let myCar = Car(engine: myEngine)
myCar.start()
이 예시에서 Car 클래스는 Engine 클래스에 '의존'한다. 왜냐하면 Car가 Engine을 사용하고 있기 때문이다. Car는 Engine이 없으면 작동할 수 없다. 이것이 바로 의존성이다. 의존성을 이야기 하다보면 ~에 의존한다 라는 말을 자주 사용하는데, '의존한다'라는 말은 "한 부분이 다른 부분을 사용한다" 또는 "한 부분이 다른 부분을 알고 있다"라고 생각하면 된다.
데이터 계층
✔️ Network
네트워크는 간단하게 Moya로 구현하였다.
✔️ Repository
Repository는 데이터의 저장, 검색, 수정 등의 작업을 수행하고, 도메인 계층(UseCase)에 필요한 형태로 데이터를 제공한다. 따라서 응답 데이터를 DTO로 디코딩하고, DTO를 도메인 엔티티(User)로 변환한다. 이런 방식으로 접근하면, API 응답 구조가 변경되어도 DTO만 수정하면 되며, 도메인 모델은 변경할 필요가 없다.
✅ DTO
DTO는 프로세스 간 데이터 전송을 위해 사용되는 객체이다. 주로 다른 계층이나 시스템 간에 데이터를 전달할 때 사용한다. 단순한 데이터 컨테이너 형식으로, 비즈니스 로직을 포함하지 않는다. DTO를 사용하면 API 변경 시 DTO만 수정하면 되므로 유지보수가 용이하고, 필요한 데이터만 전송할 수 있어 네트워크 부하를 줄일 수 있는 장점이 있다.
프레젠테이션 계층
✔️ Presenter
MVVM에서 Presenter의 역할을 하는 ViewModel이다. UseCase를 사용하여 데이터를 받아오고 Output으로 넘긴다.
✔️View
View에서는 ViewModel을 바탕으로 bind처리하면 된다. 여기서는 별다른 UI 이벤트 없이 값을 출력하게 구현했다. (간단한 예제니까 ~)
버튼을 누르면 아래처럼 데이터를 출력한다.
✔️ 파일구조
정말 간단한 예제라 파일 구조도 간단하다.
마무리
클린 아키텍처를 직접 설계해보니, 이론과 실제 적용 사이의 간극을 체험할 수 있었다. 초기에는 복잡해 보였지만, 구현을 진행하면서 각 계층의 역할과 책임이 명확해지는 것을 경험했다.
🔑 KeyPoint
1. 의존성 규칙의 중요성
도메인 계층이 외부 계층(데이터, 프레젠테이션)에 의존하지 않도록하는 것이 핵심이었다. 이를 위해 의존성 역전 원칙을 적용하여 RepositoryInterface를 도메인 계층에 정의하고, 데이터 계층에서 이를 구현하는 방식을 채택했다.
2. 계층 간 데이터 전송
DTO의 사용이 계층 간 명확한 경계를 유지하는 데 큰 도움이 되었다. 외부 데이터 구조와 내부 도메인 모델을 분리함으로써 변경에 대한 유연성을 확보할 수 있었다.
결과적으로, 클린 아키텍처를 직접 설계해보면서 "관심사의 분리"와 "의존성 관리"의 중요성을 몸소 체험할 수 있었다. 비록 초기 설정에 시간이 더 소요될 수 있지만, 장기적으로 보면 유지보수성과 확장성 측면에서 큰 이점을 제공할 것 같다.
'iOS > Design Pattern' 카테고리의 다른 글
[iOS/Design Pattern] Clean Architecture를 알아보자. (0) | 2024.08.26 |
---|---|
[iOS/Design Pattern] 코디네이터 패턴 (0) | 2024.08.02 |
[iOS/Design Pattern] MVVM에 대한 나의 고찰 (0) | 2024.05.01 |
[iOS/Design Pattern] MVVM 패턴 이해해보기 (0) | 2024.01.05 |
[iOS/Design Pattern] 예제로 알아보는 MVVM패턴 - 2 (0) | 2023.08.08 |