koin을 사용한 안드로이드 멀티모듈 아키텍쳐 클린코드

https://medium.com/@StefanoBozzoni/clean-code-multi-module-architecture-with-koin-9a40a96bc58b

Clean code on Android Multi-Module Architecture with Koin

 

안드로이드 클린아키텍쳐에서, 데이터, 도메인, 프레젠테이션과 같은 서로다른계층으로 관심사를 분리하는것은 모듈화되고 코드베이스에서 유지보수하기 쉬워지는것에 도움이됩니다. 클린 아키텍쳐에서 각각 계층은 특정한 관심사를 캡슐화하여 책임을 명확하게 분리합니다. 

이 분리는 코드 읽기와, 유지보수 그리고 어플리케이션에 다양한 구성요소에 대해 논리적으로 이해할 수 있는 능력을 향상시켜줍니다.

 

나는 멀티모듈 아키텍쳐 클린코드에 의존성을 주입하는 방법에 토픽에 대해 다룰때, 나는 문서가 많지않다는 점을 깨달았습니다. 그래서 나는 내 기사에 작성하고 다른 사람들에게 공유해야겠다고 결심했습니다.

 

내가 작업했던 프로젝트에서, 나는 다른 관심사 분리 패턴의 다양한 구현 방식을 발견했습니다. 

koin으로 의존성 주입 프레임워크를 구현할때, 개발자들은 이러한 모듈 간에 의존성을 구현하기 위해 종종 절충안을 찾아야합니다. 

 

이제 주로 사용되는 모듈들 간에 의존성 주입 방법에 대해 알아보겠습니다.

 

두개의 의존성 주입 접근방법

위에 나와있는 그림은 2개의 기본적인 접근 방법입니다. 첫번째방법은 flat style로 언급되고, 프레젠테이션은 도메인에 의존하며, 도메인에 정의된 모든 클래스와 멤버 클래스에 접근할 수 있도록 합니다. 

그러나 이것은 데이터 모듈에 모든 공개 클래스를 도메인 모듈에도 노출시키는 문제를 야기하고, 이것은 클린 아키텍쳐 원칙을 따르지 않습니다. 

이 접근 방식은 결합도가 낮고, 추상적인 코드로 이어질 수 있지만, 비즈니스 로직을 테스트할때 어려움을 초래합니다. 그리고 의존성 역전 원칙과 충돌합니다. 상위 레벨 클래스나 모듈이 하위 수준 클래스에 의존해서는 안되며, 대신 자신의 추상화에 의존해야합니다. 

클린아키텍쳐 그래프를 보면, UI 계층이 데이터 계층과 함께 가장 바깥쪽 계층 (덜 추상화 계층) 에 있음을 확인할 수 있습니다. 그 이유는 UI 계층이 안드로이드 프레임워크 구성요소기 때문입니다.

 

안드로이드에 클린코드에 대해 더 읽고 싶다면 여기를 확인해주세요.

좀 더 전형적인 예제를 통해 알아가보겠습니다. 가령, 팀멤버가 Gson을 사용해 도메인 모듈에서 객체를 json으로 변환한 후 서비스 호출을 수행하기로 결정했다고 가정해봅시다. 이렇게 하면 객체를 설명하는 문자열을 서비스에 전송할 수 있습니다. 

그리고 팀이 Gson 변환을 moshi 변환으로 변경하고 전환하기로 결정했다고 가정해봅시다.

그러한 시나리오에서는 도메인 레이어도 변경해야하지만, 만약 gson 클래스가 데이터 모듈로 위임되었다면 도메인계층을 변경할 필요가 없었을 것입니다. 덜 추상적인 계층은 아마도 더 추상적인 계층보다 변경될 가능성이 높습니다.

 

도메인 중심적인 이익의 접근방법

 

 

 

 

 

 

기타

context of 맥락에서, 관점에서 

encapsulates 캡슐화하다 

concern 관심사 

address 다루다

diffrent 다른, 다양한

compromise 절충안

figure 그림, 설정 

 is referred to ~라고 언급된다.

principle 원칙 

clash 충돌

typical 전형적인 

suppose 가정하다

relegated 위임 

we should not ~할필요가 없었을 것이다 

centric 중심적인