[Android] Clean Architecture 실전 압축 정리 - 개념

처음 학습하면서 작성한 글입니다. 필요시 추후 내용을 수정할 예정입니다.

틀린 부분이 있으면 언제든 지적해주면 감사하겠습니다 :)

---

클린 아키텍처를 공부하다 보면 모든 블로그에서 다음과 같은 이미지를 볼 수 있었다.

 

이게 뭔데 다들 이것만 올리는건데?
이게 뭔데 다들 이것만 올리는건데?

 

필자는 해당 이미지를 가장 처음 보았을 때 이런 생각이 먼저 들었다.

이는 Clean Architecture 에 대한 개념이 없이 해당 그림만 보면 이해가 안되는 것이 당연한 것이다.

(어느정도 공부하고 봐도 헷갈리는건 마찬가지다)

 

그래서 교과서적인 개념 정리보다는, 필자가 공부하고 예제를 만들어 보면서 이해한 대로 정리해보려고 한다.

교과서적인 개념 정리가 필요하면, 다른 정리가 깔끔하게 된 블로그들이 많으니 참고하길 바란다.

---

클린 아키텍처의 개념 ?

클린 아키텍처는 계층을 크게 나누어서 관심사를 분리, 각 분리된 클래스가 한가지 역할만 할 수 있도록 구현하는 방식이다.

위에 이게 뭔데 라고 했던 이미지를 확인해보면, 계층이 어떻게 나누어져 있는지 알 수 있을 것이다.

(이해는 안되지만 이런게 있다고 하고 넘어가도록 하자)

 

또한, 계층 구조에서 외부에서 내부로 의존성을 가지고 있기 때문에 내부로 갈 수록 의존성은 낮아지게 된다.

즉, 어떠한 동작을 할 때 자기보다 내부에 있는 계층이 변화하면 동작을 행하는 계층에도 영향이 있을수도 있지만 (의존성이 있지만), 자신의 외부에 있는 계층이 변화하는 것 때문에 동작을 행하는 계층에 영향이 있어서는 안 된다.(의존성이 없다).

그렇기 때문에 계층 내부로 들어갈 수록 (남에게)의존하는 성격이 낮아지게 되는 것이다.

 

예로들어 위의 계층 이미지에서 가장 바깥의 DB 와 가장 내부의 Entity 를 보자.

DB의 기준으로, Entity 가 변화(내부 계층이 변화) 하게 되면 DB 자체에서 저장할 데이터 타입이 변경될 가능성있는 등 내부의 변화로 동작을 행하는 계층에 영향을 미칠수가 있게 된다. 하지만, Entity는 실제로 사용할 데이터 클래스이기 때문에 DB 가 변경된다고 하더라도 Entity에는 아무런 영향이 없어야 하는 것이다. (영향이 있는 구조일 수도 있으나, 그렇게 되면 클릭 아키텍처에 어긋나게 된다)

반대로, Entity 는 가장 내부에 있는 계층이기 때문에 다른 어떤 계층의 변화에도 영향을 받지 않으며, 오로지 자신의 변화만이 다른 계층에 영향을 끼칠 수 있게 된다.

이것이 DB 가(바깥 계층) 의존성이 높고, Entity 가(내부 계층) 의존성이 낮다는 의미이다.

 

그래서 뭐, 이렇게 계층을 분리하고, 의존성을 내부로 향하게 하고, 이런식으로 구현을 하여 다양한 이점을 갖도록 설계를 하는 것이 클린 아키텍처라고 한다.

대충 필자에게 공부하면서 와닿았던 이점은

• 쉽게 패키지 구조 탐색이 가능해진다.
• 프로젝트의 유지 보수가 편리해 진다.
• 새로운 기능을 추가 할 때, 안정적으로 빠르게 적용이 가능하다.

정도인 것 같다.

나머지는 좀 더 큰 프로젝트에 적용하고, 운영해보면서 느낄수 있지 않을까 싶다. 아직 응애니까.

---

사용되는 3가지 계층은 ?

다음으로 생각해야 할 부분은, 안드로이드 클린 아키텍처에서 사용되는 3가지 계층. Presentation, Domain, Data 계층에 대해서 이다.

보통 순서대로 개념 설명이 많지만, 필자가 다시 보고 이해하기 쉽도록 가장 내용이 적은 것 부터 정리해보려고 한다.

 

Domain 계층 : 의존성을 가지고 있지 않은 계층. 비즈니스 로직에 필요한 Data Model 과 UseCase 가 포함되어있는 계층이다. Repository Pattern을 사용한다면, DataModel 에 대한 Repository 도 포함된다.

 

* https://heeg-develop.tistory.com/4

 

Data 계층 : Domain 계층에 의존성을 가지고 있는 계층. 말 그대로 Data 들을 control 하는 계층(CRUD)이라고 생각하면 편하다.

• API 통신과 그 결과로 가져오는 Data Entity. 내부 DB (Room) 과 DAO.
• 위의 데이터 (서버, 내부) 를 사용하기 위한 Repository 와 그 구현부.
• Data 계층 데이터(쉽게 생각해서 받아오는 데이터 형태)와 Domain 계층 데이터(쉽게 생각해서 실제로 사용하는 데이터 형태)로 변환해주는 Mapper 클래스.

가 포함되는 계층이다.

 

Presentation 계층 : Data 계층과 Domain 계층에 의존성을 가지고 있는 계층. 사실상 위에 두 계층에 포함되는거 제외하고 다 들어간다고 생각하면 편하다. 정확히 말하면, 화면과 입력에 대한 처리 등 UI와 직접적으로 관련된 부분을 담당한다.

• UI(Activity, Fragment)
• VM(각 화면에 사용될 ViewModel)
• DI
• Module

가 포함되는 계층이다.

 

정리 해보자.

우선, 의존성은 어떻게 되있는가 ?

Domain 계층은 의존성이 없다. 즉, 자기가 바뀌면 영향을 줄 뿐 다른사람의 변화에 영향을 받지 않는다.

 

Data 계층은 Domain 계층의 변화에만 영향을 받는다. 즉, Domain 계층의 무언가(클래스)를 가져와서 사용한다.

Data > Domain

 

Presentation 계층은 Domain 계층와 Data 계층의 변화에 모두 영향을 받는다. 이 때, 삼단 논법처럼 Data 계층이 Domain 계층에 의존성을 가지고 있기 때문에 Presentation 계층에서도 Domain 계층에 영향을 받는다. 라고만 생각하면 안된다. Domain 계층에서 선언된 UseCase는 Presentation 계층의 ViewModel 에서 직접 사용하기 때문에 간접적인것이 아닌 직접적으로 영향을 끼치게 된다.

Presentation > Data
Presentation > Domain

 

즉, Domain 계층은 Data 계층과 Presentation 계층 모두에서 사용된다.

다음으로, 어떤걸 선언해서 쓰는가?

Domain 계층은 비즈니스 로직에 필요한 Model 과 UseCase 가 포함된다.

Data 계층은 입맛에 맞게 변경하기 전 데이터(API, Local) 모델과 CRUD 하는 역할. Domain 의 Model 과 서로 형변환 하기 위한 Mapper 가 포함된다.

Presentation 계층은 UI(Activity, Fragment), VM, DI, Module 등이 포함된다.

 

---

나는 무엇이 가장 어려웠는가?

필자가 개념을 공부하면서 가장 헷갈렸던 부분은, Domain 계층과 Data 계층에 사용하는 Data Model 들이다.

위에는 이해한대로, 읽는 사람이 이해하기 쉽게 쓰려고 노력했지만 다른 자료들을 봤을 때 느꼈던건 뭐가 다르고 어떻게 쓰는건데? 이다.

따라서, 이 두개의 Data Model 에 대하여 필자가 이해한 것은 다음과 같다.

 

우선, Domain 계층과 Data 계층에서 사용하는 Data Model 은 서로 같을 수 있다.

필자는 이 두개가 같은데 왜 따로 쓰지? 항상 다른거니 Mapper 를 쓰는건가? 뭐가 다른건가? 라는 의문이 있었다.

제대로 이해를 못했기 때문이지만

쉽게 예로들어 생각해보자.

간단하게 서버에서 id, title을 받아와서 뿌려주는 앱이 있다고 가정해보자.

서버 api 를 통해서 두 개의 값을 가져오고, 그것을 뿌린다고 한다면 Data 계층의 Model 과 Domain 계층의 Model 은 동일하게 id, title 값을 가지도록 구현되어야 하며, Mapper 클래스에서는 그냥 그대로 전달만 해주면 된다.

 

두 개의 Model 이 다르기 위해서는, 쉽게 생각하여 서버 API 를 통하여 좀 더 많은 정보를 가져오는 경우를 생각하면 된다.

위와 똑같이 보여지는 상황에서 서버 API 를 통해 id, title, subTitle, PassWd, UserName, ... 의 데이터를 가져온다고 가정해보자.

Domain 계층의 Model 에서는 id, title 만을 사용해서 뿌려주고 있기 때문에 Domain Model 은 id, title 값만 가지도록 하면 되지만, Data 계층의 Model 에서는 API 의 응답으로 가져오는 값을 모두 선언해야 한다. 또한, Mapper 클래스에서 Data to Domain 으로 데이터를 넘길 때 필요한 데이터 id, title 만 추출하여 넘겨주는 작업을 진행해야 한다.

 

다음으로, Domain 계층의 Model 과 Data 계층의 Model 은 어디서 사용되는가?

Data 계층의 Model 은 Data 계층에서만 사용되고, Domain 계층의 Model 은 Presentation 계층에서도 사용된다.

위의 설명들을 제대로 이해했다면 이해가 될 것이다.

Domain 계층의 Model 은 실제로 사용하는 데이터 클래스라고 볼 수 있다. 여기서 실제로 사용하는게 무엇인가? 가장 대표적인 것으로는 UI 의 변경이다.

이것 하나만 보아도 Presentation 계층에서 데이터를 Domain 계층의 Model 을 실제로 사용하여 동작하는 것을 알 수 있다.

 

그렇다면, Data 계층의 Model 은 어떻게 사용하는가 ?

Data 계층을 설명 할 때, Data 를 컨트롤 한다고 했던 부분이 있다.

DB(Local), 서버 API 를 통해서 Data 를 저장. CRUD 를 사용하여 필요한 데이터를 꺼내어 Mapper 를 통해 Domain 계층의 Model 로 데이터를 넘긴다.

그 다음은 Domain 계층의 Model 로 사용되기 때문에 Data 계층의 작업은 끝난 것이다.

 

---

솔직히 텍스트로만 봐서 이해하는 듯 싶지만 막상 적용을 하려고 생각하면 막막하기 마련이다.

결국 필자도 공부하면서 계속 생각했던건 이거다.

그래서, 어떻게 구현하면 되는건데?

 

따라서, 다음 포스팅은 실제로 구현한 예제를 사용하여 이해한 대로 작성해 보았다.

https://heeg-develop.tistory.com/3

[Android] Clean Architecture 실전 압축 정리 - 예제