티스토리 뷰

지식쌓기

Android - Clean Architecture 적용 중... 훔....

바나나쥬스 2022. 8. 10. 22:55

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

 

Clean Coder Blog

The Clean Architecture 13 August 2012 Over the last several years we’ve seen a whole range of ideas regarding the architecture of systems. These include: Though these architectures all vary somewhat in their details, they are very similar. They all have

blog.cleancoder.com

 

이런저런 클린 아키텍쳐 관련된 많은 글들을 보고 예제들도 많이 봤지만..

역시나 실무에 적용하다 보면 여러가지 예외 상황들을 맞이하게 된다.... 이런 고민 하는 사람없나 -_-? 글도 잘 못찾겠고...

 

domain 모듈을 순수 코틀린 모듈로 한 경우 

 

1. Bitmap을 못쓴다. 

- android.graphics 에 있기 때문

- 난 그냥 Bitmap 을 넘겨받고 싶은데...

- ByteArray 로 하면되는데 zxing 은 글케 안주네...

- BitMatrix 라고 넘겨주는데.... 이건 zxing에서 정의한 모델... domain 영역에 정의해서 쓰긴 부적합... 물론 Bitmap도 부적합..

- 그래 Bitmap은 domain영역에 정의 하는 건 아닌것 같다..

https://github.com/android10/Android-CleanArchitecture/issues/182

 

How to pass the android dependent data from data-layer to presentation-layer · Issue #182 · android10/Android-CleanArchitectur

Hi all, I am currently learning about android-clean architecture. Related to #64 , I am thinking about how to pass the Android-specific data (like bitmap) from data-layer to presentation-layer thro...

github.com

- 훔 Generic을 써볼까? 되나? 

 

2. Base64

- android.util.Base64 대신 java.util.Base64 를 쓰면되겠지..

- 근데 java.util.Base64 는 api 26 버전에 추가됬네 -_-?

- decoding 하고 encoding 하고 이런게 비지니스 로직 아닌가 -ㅅ-?

- data영역에서 해주고 넘겨버릴까

 

어차피 딴데 떼다가 갔다 쓸 일도 없는데 너무 엄하게 가는것인가 ... 

iOS 친구는 그렇게 까진 안했다고 한다

 

app, domain, data 의 의존성관계

클릭아키텍처 대로라면 의존성은 아래와 같이 되어야 한다.

app -> domain

data -> domain

domain -> 없음

 

하지만 대부분 아래처럼 의존성을 가진다 (나도 이렇게 함)

app -> data, domain

data -> domain 

domain -> 없음

 

그런데 data 레이어에 정의된 Repository Implementation class 들을 생성해서 주입시켜야 하는데 첫번째 처럼 하려면 어디서 생성해서 주입시켜야 하나? 대부분 app 영역에서 di를 하니까.. 

 

아래 블로그 예제 보려는데 소스가 없어졌네.. 쩝

https://fivenyc.medium.com/android-architecture-part-4-applying-clean-architecture-on-android-hands-on-source-code-8da287a0e0a2

 

Android Architecture Part 4: Applying Clean Architecture on Android, Hands on (source code…

Let’s get our hands dirty with clean code and turn that blank canvas into robust and versatile architec

fivenyc.medium.com

 

UseCase 정의

대부분의 예제들을 보면 하나의 동작당 하나의 UseCase 를 정의하고 한가지의 동작만 하고 있다. 

예를들어 위 블로그 처럼 

AddNewFeedUseCase

GetFeedArticleUseCase

이렇게 하나의 동작마다 정의 하고 있다..

그냥 FeedUseCase 하나 만들고 그 안에서 addNewFeed, getFeedArticle 이렇게 두 동작을 정의하면 안되나?

(iOS 친구는 이렇게 했다고 한다.. )

하나하나 하면 UseCase를 겁네 많아지는데... 훔..

근데 구글 IO 소스보니 구글도 저렇게 하나하나 정의했더라... invoke 로..

 

UseCase 의 의미가 유저가 이 서비스를 통해 하고 하는 것..

고민고민 ㅋㅋ

 

Mappers

대부분 Mapper 들을 data layer에 넣어두고 

data layer에 정의한 모델을 domain 영역의 entity 모델로 변환 시켜주고 있다.

그런데 난 거의 그 모델들이 완전 동일하여 그냥 domain 영역에 하나만 정의하고 딱히 mapper 를 두고 변환시켜주지 않고 있다. 

오히려 presentation (app) 영역에 mapper 를 둬서 domain 의 모델을 app 영역의 모델로 변환시켜주고 있다.

왜냐하면 app 영역의 모델은 Parcelable 해야 하는 경우가 있기 때문..

 

결국...

쉽게 가는걸로.. ㅜㅜ

domain 레이어도 android library module로 정의

그래서 domain 레이어 모델클래스에 Parcelable도 정의해 버리고 mapper들은 걍 제거

이렇게 한 결정적인 원인이..

뭐였더라.. 낼 다시 업뎃... 

저작자표시