Clean Architecture in Android !

Clean Architecture ?

변화에 잘 대응할 수 있는 코드

Is my [Use case] code bound to [Platform] ?

내 유스케이스가 플랫폼에 종속적일까 ?

"Architecture is about Intent, not frameworks" - Uncle Bob

아키텍처는 의도에 관한 것이지, 프레임워크에 관한 것이 아니다.

건물에 도면에는 건물이 건물이 어떻게 지어져야 하는지 알려줍니다. 이처럼 소프트웨어 아키텍처는 기능을 수행하는 어플리케이션이 어떻게 만들어지는지에 대한 정보를 알려주어야 하는 것이 올바른 아키텍처 인 것입니다.

하지만 이 소프트웨어의 아키텍처가 이를 알려주지 않고, 사용하는 프레임워크만 알려줄 것이라면 어떻게 될까요? 좋은 아키텍처가 될 수 없을 것입니다.

 

 

가령 유스케이스의 예를 들어보겠습니다. :

[Usecase] Buy Goods.

1. Buyer calls in with a purchase request
2. Company captures buyer's name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery, dates, etc.
4. Buyer signs for order.

이 UseCase를 구성하는 내용 중 단 하나도 IO에 대한 내용이 없습니다.

즉 프레임워크도, 데이터베이스도 전부 유스케이스에 담겨져 있지 않다는 뜻이 됩니다.

우리가 유스케이스를 중심으로 어플리케이션을 만들어야 한다고 말하지만, 정작 아키텍처는 플랫폼에 종속되는 경우가 많다는 것이 클린 아키텍처의 문제 요소라고 말하고 있습니다.

클린 아키텍처의 궁극적인 목표란?

유스케이스를 중심으로 외부 세계외 것들 (Interest) 를 분리하는 것입니다.

UseCase 구현은 Entity라는 것으로 만들어지는데 Entity는 데이터베이스에서 사용되는 Entity의 용어가 아닌 비즈니스 룰을 정하는 의미입니다.

대부분의 비즈니스 룰은 직접적으로 서버에 통신하던지, 데이터베이스에 접근하는 방법을 이용합니다. 그리고 이 최종적인 결과는 UI 혹은 적절한 http 응답으로 보여질 것입니다.

그래서 만약 우리가 이 개념을 유스케이스가 엔터티를 이용하고, 엔터티가 비즈니스 룰을 표현한다면 비즈니스 룰을 표현하기 위해 외부세계와 많은 접촉을 해야할 것입니다. 그렇게 된다면 유스케이스는 외부에 많은 의존을 하는 형태로 존재하겠죠?

클린아키텍처 창시자인 Uncle Bob은 이러한 원 모형에서 Presenters를 추가하는 것을 제안했습니다. 즉 느슨하게 결합하는 interface adapter를 제안해 본인만의 유스케이스를 구현하는 것이죠.

클린아키텍처의 핵심은 "비즈니스 로직을 바뀔 수 있는 모든것으로부터 분리하자" 라는 생각이다.

"Separate Business Logic from the Changeable"

기획이 바뀌면 유스케이스 조차 바뀌지 않느냐! 라고 반박하는 사람이 있을 겁니다.

당연히 기획이 바뀌면 모든 것이 바뀌게 됩니다.

하지만 여기서 말하는 바는, 유스케이스가 달라지지 않았음에도 불구하고 유스케이스를 고쳐야할 일이 생겼다면 안좋은 아키텍처의 신호라는 점이라는 것을 알아줬으면 하는 것입니다.

만약 이런 상황에서 유스케이스 코드를 바꿔야 한다면 의존성 규칙을 만족하지 못했기 때문일 것이죠.

이렇기에 Uncle Bob은 의존성 규칙을 제안했습니다. 의존성 규칙이란 안쪽 원으로부터 바깥쪽 원을 직접적으로 호출할 수 없고 오직 원 안의 의존성만 가질 수 있는 것입니다.

---

클린 아키텍처에서는 유명한 다이어그램이 존재하는데 네가지의 섹션을 제시합니다.

• 도메인 로직: 엔티티, 데이터, 모델
• 비즈니스 규칙: 유스 케이스
• 인터페이스 어댑터: 프리젠터, 프리젠테이션 로직
• 프레임워크/드라이버: UI, 네트워크, 데이터베이스

안드로이드의 계층을 4개로 사용자에게 보여지는 로직과 관련된 Presentation 레이어, 네트워크를 포함한 데이터를 가져오는 Data 레이어, 사용자의 유스케이스로 분리되는 Domain 레이어, 사용자의 개념을 정의하는 Entity 레이어 네 개로 나눴습니다. 이 네 레이어 간의 의존성은 안쪽으로만 발생해야 합니다. 즉, 가장 하단부의 레이어일 수록 가장 의존성이 낮아야 합니다.

종속성 규칙(dependency rule): 소스 코드 종속성은 오직 내부로만 향할 수 있고 내부의 원은 바깥 원의 아무것도 알수 없습니다.

어떻게 나누어야 할까요 ?

클린 아키텍처(clean architecture) 는 다음과 같은 시스템을 생산하는 일련의 관례(practices)를 의미합니다.

• 프레임워크 독립적
• 단위 테스트 가능
• UI에 독립적
• 데이터베이스에 독립적
• 기타 외부의 모든 서비스 제공(agency)과 독립적

---

먼저 Presentation 은 의존성이 높은 UI 레벨의 레이어이므로 이 곳에서 패턴적용이 가능합니다. ( Fragment, View Model, LiveData)

Domain 은 비즈니스 로직을 담고 있는 레이어 입니다. 비즈니스 로직에서 필요한 Model, Presentation, Service를 거쳐 Data 레이어를 이어줄 UseCase, 그리고 중간에서 비즈니스 로직을 책임질 Service 구현체들, 그리고 Service 가 가져올 데이터 도메인의 Repository의 인터페이스가 자리 잡고 있습니다. (Usecase, Entity, Repository)

Data 는 Repository 와 DataSource, 그리고 Data 그 자체인 Entity 가 있습니다.(Network, DB, Memory)

Clean Architecture 의 이점은 ?

독립적으로 어플리케이션 코어를 개발할 수 있다는 것

[independent of X] ----> Testable !

어떤 비즈니스로직을 담고 있는 UseCase를 테스트하기 위해 외부 요인을 전혀 필요로 하지 않습니다.

유닛테스트로 테스트 할 수 없는 경우가 종종 존재합니다.

1. 데이터베이스로부터 실제로 값이 잘 불러와질 수 있는지
2. 의도한 바로 UI가 그려지는지
3. 그리고 그것이 실제로 메인액티비티와 가상의 프로그래밍 뷰가 잘 바인딩 되어있는지

그러나 이밖에 경우에는 적절한 인터페이스를 주입하는 것으로 유닛테스트가 가능해집니다.