[iOS] Clean Architecture, 내 생각

Clean Architecture

아래 글의 원문은 엉클밥의 블로그입니다.

• 엉클밥 (로버트 C 마틴) - https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

---

도움되는 Reference

• 갓제드 - https://zeddios.tistory.com/1065
• 곰튀김 - https://www.youtube.com/watch?v=jVyA5DV6r8w

---

클린 아키텍처에 대해 정리해보자

이 글은 유명한 로버트 C 마틴 (엉클밥)이 제안한 아키텍처이다.

엉클밥은 그동한 개발하면서 많은 아키텍처를 보았는데 이들 세부사항은 다르지만 서로 유사성을 가지고 있다.

아키텍처들의 동일한 목표는 관심사 분리이다. 이를 위해 소프트웨어를 계층(layer)로 나누어 관심사 분리를 달성하고자 한다.

이러한 각 아키텍처는 다음과 같은 시스템을 생성하게 된다.

1. Independent of Framework : 아키텍처는 소프트웨어 라이브러리에 영향을 받지 않는다.
2. Testable : 비즈니스 로직은 UI, DB, Web Server 또는 기타 요소 없이 테스트가 가능하다.
3. Independent of UI : UI는 시스템의 다른 부분을 변경하지 않고도 바꿀 수 있다! 비즈니스 로직을 바꾸지않고 웹 UI를 콘솔 UI로 바꿀 수 있게 된다.
4. Independent of DB : 현재 사용 중인 DB를 다른 것으로 바꿀 수 있다. 비즈니스 로직은 DB에 바인딩되지 않기 때문이다. (바인딩 : 각종 값들의 성격이 확정되는 것)
5. Independent of any external agency : 실제로 비즈니스 로직은 외부 세계(outside world)에 대해 전혀 알지 못한다.

맨 위의 다이어그램은 이러한 모든 아키텍처를 하나의 실행 가능한 아이디어로 통합하려는 것인데 그것이 바로 Clean Architecture이다.

The Dependency Rule

원은 소프트웨어의 여러 영역을 나타내는데, 일반적으로 멀어질 수록 소프트웨어의 수준이 높아진다.

바깥쪽 원 - mechanisms, 내부 원 - 정책

아키텍처가 작동하도록 하는 우선 규칙은 종속성 규칙이다.

• 소스 코드 종속성(souce code dependencies)은 안쪽만 가리킬 수 있다.

• 내부 원의 어떤 것도 외부 원의 어떤 것에 대해 전혀 알 수 없다.

• 외부 원에 선언된 이름은 내부 원에 있는 코드에서 언급되지 않아야 한다. 함수, 클래스, 변수 등이 포함된다.

• 마찬가지로 외부 원에서 사용되는 데이터 형식은 내부 원에서 사용해서는 안된다.

  → 즉, 바깥 쪽 안의 원이든 안쪽 원이든 서로 영향을 주지 않는 것이다.

Entity

Entity는 Enterprise wide 비즈니스 규칙을 캡슐화한다. 가장 일반적이고 높은 수준의 규칙을 캡슐화한다. 외부가 변경될 때 변경될 가능성이 가장 적다.

특정 애플리케이션에 대한 운영 변경은 엔티티 계층에 영향을 주지 않아야 한다.

Use Case

우선, Use Case란 시스템의 동작을 사용자의 입장에서 표현한 시나리오를 말한다. 예를 들어 ToDo앱을 생각해본다면 ToDo 앱에서 우리는 무엇을 하게 될까?

할일을 등록/수정/삭제하게 될 것이다. 이런 일들을 Use Case라고 할 수 있다.

이 계층의 소프트웨어에는 비즈니스 규칙이 포함되어 있다. 시스템의 모든 Use Case를 캡슐화하고 구현한다.

이 레이어의 변경 사항은 Entity와 DB, UI 또는 Framwork와 같은 외부성에 대한 변경으로 인해 영향을 받지 않는다.

하지만 Use Case의 세부 사항이 변경되면 영향을 받는다. 사용자의 시나리오가 바뀌기 때문이다.

Interface Adapter

Interface Adapter에는 Controllers, Gateways, Presenters가 해당된다.

이 계층에 데이터가 들어오면 Entity 및 Use Case에 가장 편리하면 format에서 사용중인 Framework에 가장 편리한 format으로 변환한다.

즉, DB는 딱 이 계층까지만 알 수 있으며 이 내부 원은 전혀 알 수 없다.

(여행용 Adapter를 생각하면 이해가 쉽다. 220V와 110V를 변환해주는 여행용 Adapter... 현재 콘센트는 꽂히는 주체가 220V인지 110V인지 알 필요가 없다.)

Frameworks and Drivers

가장 바깥 쪽 레이어는 일반적으로 DB, 웹 프레임워크 등과 같은 프레임워크와 도구로 구성된다. 일반적으로 이 레이어에는 다음 원과 내부로 통신하는 glue code 외에 많은 코드를 작성하지 않는다.

Only Four Circles?

그럼 딱 4개의 원만 사용할 수 있는가? 아니다. 원은 얼마든지 추가할 수 있으며 Dependency rule이 항상 안쪽을 향하게 하면 된다. 안쪽으로 갈 수록 추상화 수준이 높아진다.

Crossing boundaries (경계를 넘어)

다이어그램의 오른쪽 하단에는 우리가 원 경계를 어떻게 넘었는지 보여주는 예시가 있다.

분홍색 선을 보면 Controller → Use Case Interactor → Presenter로 향하는 것을 볼 수 있다.

"Use Case Interactor → Presenter" ⇒ 앞에서 본 The Dependency Rule을 다시 보면 Use Case에서 Presenter로 직접 연결하는 것은 안되기 때문에 Use Case Output Port라는 것을 두어 Use Case는 Output에 있는 Interface를 호출하고 Presenter는 해당 Interface를 구현한다.

Use Case에서 직접 Presenter로 접근하지 않고 Interface를 두는 것이 중요한 점임을 기억해두자.

Conclusion

소프트웨어를 계층으로 분리하고 The Dependency Rule을 준수함으로써 테스트 가능한 시스템을 만들 수 있다.

---

내 생각으로 마무리하자면...

처음 클린 아키텍처를 봤을 땐 이게 대체 무슨 소리인가.. 하는 생각이 너무 많이 들었다. 이해하기도 어려웠다. 엉클밥 글을 봐도 뭔소리.. 이러고 있었는데 제드님 글을 한번 보고 엉클밥 글을 다시 보니 이해가 됐다. 어느정도는 아 이게 클린 아키텍처구나 알 수 있게 된 거 같다.

어쨌건 클린 아키텍처에서 중요한 것은 Dependency Rule을 지키는 것이 중요하다고 생각이 든다. 최대한 관심사를 분리하는 것!!! 이걸 지키기 위한 노력을 하는 것이 중요하다고 생각된다.

결론 : 어려웠다. 여러번 보면 좋을듯하다.