🏛 Android의 Clean Architecture에 대해 알아보자 !

오늘은 제가 Android 개발자로 활동하는 MARU와 관련된 주제를 가지고 왔습니다! MARU의 Android 개발자들은 Clean Architecture를 지향하며 열심히 개발하고 있는데요, 오늘은 이 Clean Architecture가 무엇인지 알아보고, MARU가 이를 어떻게 소화하고 있는지 소개해보려고 합니다. 사실 최근까지 Clean Architecture에 대해서 잘 몰랐었는데, MARU라는 좋은 기회로 Clean Architecture를 공부하고 경험할 기회가 생겨 기쁩니다. 용어가 다양하고, 추상적인 개념들을 이해하기 어려웠지만, 최대한 공신력 있는 자료를 보고 소화하려 노력했습니다 ! 글에 대한 피드백 항상 환영입니다 :) 그럼 오늘도 화이팅입니다 🌿

1️⃣ Clean Architecture가 무엇일까

---

개발자들 사이에서, 과녁 모양 그림 이라던가, 양파 모양 구조도라는 표현을 쓰곤하는데요. 바로 Robert C. Martin (Uncle Bob)의 Clean Architecture 그림을 지칭하는 말입니다 🤪

Clean Architecture의 전부를 아래 그림이 표현하고 있다고 할 수 있습니다.

왜 Clean Architecture를 사용할까 ?

• Clean Architecture의 창시자인 Robert C. Martin (Uncle Bob)가 운영하는 The Clean Code Blog에 의하면, Clean Architecture가 시스템에 주는 이점은 아래와 같다고 합니다. 한 문항씩 해석해가며 설명하겠습니다.

1. Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
2. Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.
3. Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
4. Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
5. Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.

1. Clean Architecture는 프레임 워크에 독립적입니다.
   • Clean Architecture는 일부 기능이 포함된 라이브러리 (곧 프레임워크)에 의존하지 않습니다.
   • 이를 통해 프레임워크의 제약에 시스템을 맞추는 것이 아니라, 시스템의 도구로써 프레임워크를 활용할 수 있게 합니다.
2. Clean Architecture는 테스트를 용이하게 해줍니다.
   • The business rules(Entity)를 테스트하는데에 외부 요소를 필요로 하지 않습니다.
3. Clean Architecture는 UI에 독립적입니다.
   • 다른 시스템 변경 없이, UI를 쉽게 변경할 수 있습니다. (UI 변경의 용이성을 줍니다.)
     • 예들 들면, 웹 UI에서 Console UI로 변경한다 할때, The business rules(Entity)를 변경없이 그대로 사용할 수 있습니다.
4. Clean Architecture는 DB와 독립적입니다.
   • The business rules(Entity)이 DB에 바인딩 되지 않으므로, DB의 종류를 쉽게 변경할 수 있습니다.
     • 예를 들면, Oracle에서 SQL Server, for Mongo, BigTable, CouchDB 등등으로 쉽게 변경 가능합니다.
5. Clean Architecture는 외부와 독립적입니다.
   • The business rules(Entity)는 외부에 대해 알필요가 없고, 전혀 알지 못합니다.
     • 이 덕분에 1-4의 이점을 가져올 수 있는 것입니다.

Dependency Rule

• (위 그림 출처) 위 그림에서 의존성 법칙은 Entites로 향하는 화살표를 의미합니다. 즉, 항상 원의 안쪽 방향으로만 의존성이 존재해야하고, 바깥쪽 방향으로의 의존성은 존재하지 않아야한다는 의미로 해석할 수 있습니다.

  • 그림에 따르면, 바깥 쪽의 요소 A는 안쪽의 요소 B를 필요로 합니다.

    "A가 B를 필요로 한다." 라는 의존 관계를 UML 의 표현을 빌려, A - - -> B로 표현할 수 있습니다.

  • 그렇다면 과연, 안쪽의 요소 B는 바깥 쪽의 요소 A를 절대 필요로 하지 않을까요?

    • 아래에서 repository 에 대해 설명하며, 다시 언급하겠지만, 그렇지 않습니다. 다만 이 B가 의존 관계를 회피하여 A를 사용할 뿐입니다. 아래에서 의존성 역전 법칙과 함께 다시 말씀드리겠습니다.

• 의존의 방향은 변경의 유연성과도 관련이 있습니다. Clean Architecture에선, 의존의 방향이 안쪽으로만 향하기 때문에, 바깥쪽에 있을수록 변하기 쉬운, 안쪽에 있을수록 변하기 어려운 요소라 이해할 수 있습니다.

2️⃣ Clean Architecture의 Layer들

---

(아래 그림 출처) 아래 그림은 위에서 보았던 Clean Architecture 그림을 90도 회전한 모습입니다. Clean Architecture의 각 Layer들을 설명하기 위해 아래와 같이 활용되었습니다.

Presentation Layer

위 그림의 Presenter를 Presenters뿐만 아니라, ViewModels도 포괄하기 위한 말로, Controllers라 부르겠습니다.

• UI (Activities & Fragments), Controllers (Presenters/ViewModels) 를 포함합니다.

• Controllers (Presenters/ViewModels)은 1개 이상의 Use cases를 실행합니다.

• UI은 UI 각각의 Controllers (Presenters/ViewModels)에 의해 조정됩니다.

• Presentation Layer는 Domain Layer을 대상으로 의존성을 가집니다.

  Presentation Layer - - - > Domain Layer

Domain Layer

• Entities, Use cases, Repository Interfaces를 포함합니다.

• Use cases는 data와 1개 이상의 Repository Interfaces를 결합합니다.

• Domain Layer는 가장 안쪽의 레이어입니다. 앞서 언급한 의존성 법칙에 의해, Domain Layer는 다른 레이어를 대상으로 의존성을 가지지 않습니다. 다른 레이어가 Domain Layer를 대상으로 의존성을 가질 뿐입니다.

  어떻게 Domain Layer는 Data Layer에 대힌 의존성도 가지지 않을 수 있나요?

  한마디로 답변하자면, SOLID 원칙 중 의존성 역전 법칙에 해당하는 interface를 사용한 추상화 덕분입니다.

  Interface 추상화가 없었다면, Domain Layer의 Use cases가 Data Layer의 Repository를 사용해야합니다. 즉, Domain Layer - - - > Data Layer 라는 의존이 생겨나게 됩니다.

  하지만 Domain Layer는 Repository를 추상화시켜 사용하고 있기 때문에, 위와 같은 의존이 생겨나지 않게 되는 것입니다. 즉, Domain Layer는 Data Layer에서 구현될 Repository Interfaces를 사용하면서, 의존을 회피하게 됩니다.

  이것이 바로 Repository Interfaces가 Domain Layer에 포함되는 이유이자, Repository Implementations가Data Layer에 포함되는 이유 라고 볼 수 있습니다.

  의존성 역전 법칙을 한마디로 ?

  High-level modules should not depend on low-level modules, both should depend on abstractions.

Domain Layer의 특징 ‼️

• Domain Layer 가장 중요한 레이어 입니다 ‼️ 따라서 다른 레이어들과는 달리, 잘 바뀌면 안됩니다.
  • 이 Domain Layer에 소프트웨어의 중심이 되는 The business rules(Entity)가 포함됩니다.
• Domain Layer는 다른 레이어를 대상으로 의존성을 가지지 않습니다.
  • 즉, Domain Layer는 프레임 워크(Android Platform)에 의존성을 가지지 않고, 오직 언어 단(Kotlin Module)에 대해서만 의존성을 갖습니다.
    • 따라서, 프레임 워크간의 Domain Layer 재사용도 가능합니다.

Data (DataSource) Layer

• Repository Implementations, 1개 이상의 Data Sources를 포함합니다.

  Data Layer의 Repository Implementations

  Data Layer가 가진 책임 중 하나로, Domain Layer가 사용하는 Repository Interfaces에 대한 구현을 이야기 할 수 있습니다. Domain Layer는 Data Layer가 구현해줄거라 생각하고 Repository Interfaces를 사용했기 때문입니다.

• Repository는 다른 Data Source들을 결합/조정합니다.

  • Repository 여러 Data Source들을 결합하는 경우로, Local Data Source과 Remote Data Source의 결합에 대해 이야기할 수 있습니다.

    dataSource와 dataSourceImpl

    Data Layer의 Data Source도, 위에서 봤던 의존성 역전 법칙의 적용으로, 추상화 되어 interface와 Implementations으로 구성됩니다.
    즉, Repository - - -> Data Source의 의존에 대한 회피입니다.

    한편, 이렇게 의존을 없애면, Data Source의 변경시, Repository에 대한 영향을 줄일 수 있습니다.

    Repository 패턴을 한마디로 ?

    데이터 출처 (data source)와 관계 없이, 동일한 인터페이스로 데이터를 사용할 수 있게 하는 패턴을 의미합니다.

    예를 들면, Repository 패턴은 Room(내부저장소)으로 관리되는 데이터와 (local data source data) , Retrofit2를 통해 받아오는 데이터(remote data source data)의 구분을 없애, 해당 데이터를 사용하는 Domain Layer가 데이터 출처(data source)를 알 필요 없게 해줍니다.

• Data Layer는 Domain Layer을 대상으로 의존성을 가집니다.

  Data Layer - - - > Domain Layer

3️⃣ Clean Architecture의 Data Flow

---

콜과 스트림 방식에 대해 공부 중입니다 ~,~

#️⃣ Reference

---

• (⭐️ 추천) ProAndroidDev : Clean Architecture Guide (with tested examples): Data Flow != Dependency Rule
• fernandocejas: Architecting Android...Reloaded.
• fernandocejas: Architecting Android...The evolution.
• fernandocejas: Architecting Android...The clean way?
• @ Droidcon Zagreb 2016: Clean architecture on Android
• Young-Ho Cho: 애플리케이션 아키텍처와 객체지향
• The Clean Code Blog : The Clean Architecture