-AndroidDeveloper 공식문서
=>https://developer.android.com/topic/modularization?hl=ko

-앱의 규모가 커지면 필연적으로 기능별 , 계층별로 모듈을 분리할 필요가 생긴다. 이렇게 모듈을 분리하는 것이 실질적으로 앱의 아키텍처에 어떻게 영향을 미치고 개선 될 수 있을지 아는 것은 중요하다.

-모듈을 분리할 때 어떻게 분리하면 좋은지와 충돌의 문제등을 어떻게 해결하는지 아는것 또한 중요하다.

모듈이란?

-모듈이라는 것은 "잘 정의되어진 범위와 논리적으로 타당한 의존성들 그리고 분명한 담당자를 가지고 있고 앱에서 재사용이 가능하도록 의도된 코드의 덩어리"를 의미한다.

-예를들어 Account 모듈이 있다면 로그인/로그아웃/인증관련 코드등이 모여 있어야한다.

-모듈이라는 것 자체는 하나의 독립적인 응집성을 가지고 있고 , 해당 응집성을 배경으로 해서 어떠한 앱을 전체적으로 구성하고 있는 레고 블럭과 같은 벽돌처럼 사용 될 수 있는 것을 의미한다.

모듈을 나눠야 하는 이유

1-프로젝트 코드의 복잡도 낮추기 위해서

-프로젝트의 규모가 커지고 팀원이 늘어나도 생산성의 저하를 방지 할 수 있다. 각각의 부서들과 팀원들에 따라서 자신의 책무를 명확히 지정해줌으로서 코드베이스의 복잡도로부터 팀과 팀원들을 보호할 수 있게 해준다.

2-의존도 낮추기 위해서

-해당 모듈 내부에서만 영향을 줄 뿐이지 다른 모듈을 통해서 해당 모듈을 바꾸는 등의 하나의 모듈이 또 다른 모듈에게 영향을 주는 것들을 최소화 시킬 수 있다. 개발자가 내부 코드들을 사용해서 특정 모듈을 사용한다고 하면 보다 코드의 복잡성을 낮추면서도 테스트도 쉽게 해준다.

3-개발자간 자율성 높이기 위해서

-자신의 모듈에 대해서 책임감을 가지고 담당 할 수 있으므로 자기의 영역안에서 자유롭게 코드를 작성 할 수 있다.

-외부 모듈의 영향으로 부터 잘 격리된 코드를 이용해서 독립적으로 일할수 있으므로 눈치보지 않고 일할 수 있다. 인프피인 나에게는 정말 좋다.

4-빌드속도 높이기 위해서

-기본적으로 모듈을 쪼갤수록 평균 4배~5배 정도 빨라진다. 단, 의존관계가 명확할 때에만 해당한다.

-만약 빌드 성능에 영향을 주는 무언가가 있을 때에 이걸 특정 모듈안으로 격리시키면 해당 모듈만 빌드 속도가 느려져서 다른 모듈의 빌드 속도가 느려지지 않는다.

5-사용자에게 필요한 기능만 선택적 제공하기 위해서

-중요성은 있지만 굳이 사용하기 싫다면 필요할때만 다운로드 하고 필요없을 때는 삭제하는 것이 가능하다. 이렇게 함으로서 앱의 크기와 앱의 초기 실행 속도를 줄일 수 있다.

모듈을 나눌때 고려해야 할 것들

1-해당 모듈의 역할이 무엇인지

-어떠한 서비스와 기능들을 제고하는지에 대한 고민

-다른 모듈이 사용 할 수 있는 인터페이스가 정의되어있는지에 대한 고민

2-해당 모듈은 복잡성을 캡슐화하고 있는지

-내부에 있는 복잡성을 잘 감추고 있어서 필요한 인터페이스만 바꿔서 사용 할 수 있는지에 대한 고민

-만약 해당 모듈에 있는 어떠한 세부사항 또는 내용들을 다 알지 못한다면 다른 모듈에서 해당 모듈을 편리하게 사용 할 수 없다면 애초에 분리시키면 안되는 모듈일 가능성이 있는 것이다.

3-해당 모듈 내부의 코드들을 좀 더 세분화 할 수 있는지

-모듈 내부의 코드들을 더 세분화한다면 더 효율적인 모듈이 될 수 있는지에 대한 고민

4-여러 모듈로 굳이 나눠야 하는지

-억지로 코드들을 여러 모듈들로 나눈것은 아닌가에 대한 고민

-여러 모듈들로 나뉘어진 코드들을 더 효율적인 모듈들로 재구성 할 수 있는지에 대한 고민

5-정리

-그러니까는 굳이 억지로 멀티모듈을 만들꺼야가 아니라 멀티모듈화하는 작업에 대한 명확한 이유가 존재할 때 멀티모듈화해야 된다는 것이다. 단순히 맹목적으로 멀티모듈을 해야겠다는 must의 개념이 아니라 should의 개념이여야 된다. 멀티모듈하는 이유가 앱의 발전에 효율적으로 기여하는 방향으로 멀티모듈화를 하려고 해야한다.

모듈을 나누는 절대적인 기준들

1-캡슐화에 따른 분리 기준

-여기서 말하는 클래스 기준의 캡슐화 개념이 아니라 굉장히 큰 규모의 캡슐화를 의미하는 것이다. 즉, 각각의 모듈이 자체적으로 완결성을 가지고 독립적으로 기능하도록 해야 한다는 것이다.

-만약 A모듈이 B모듈의 내부동작에 강하게 의존하고 있다면 A모듈을 B모듈의 복잡성으로부터 격리하지 못한것이다. 이렇게 할 바에는 애초에 "B모듈을 잘 구성하거나" , "B모듈이 A모듈의 일부로 구성되거나" 하는 것이 더 좋다. : 억지로 모듈화를 하지 말라는 것이다.

복잡성 관리

-큰 규모의 캡슐화를 진행하면 시스템의 복잡성을 관리 할 수 있다. 각각의 모듈이 자체적으로 완결성을 가지고 독립적으로 기능하도록 함으로서 전체적인 코드의 개발과정에서 유지보수와 코드를 이해하는것이 더 좋아진다.

의존성 최소화

-모듈A가 모듈B의 내부동작에 강하게 의존하면 모듈B의 변경 사항이 모듈A에 영향을 미치므로 클린아키텍처의 원칙에 위반된다. 따러서 모듈간의 격리를 최대한 지향해야 한다.

2-재사용성에 따른 분리 기준

-재사용성이 높은 기능에 따른 분리를 진행해야 한다. 재사용성이 높은 기능들을 분리하여 모듈화함으로서 다른 모듈에서 재사용이 가능하도록 할 수 있다. 이렇게 재사용성이 높은 모듈은 다른 모듈과 결합도가 낮아야 한다.

-Utility 모듈은 어디에서도 참조될 수 있는 모듈이다.

결합도 낮추기

-재사용성이 높은 모듈은 다른 모듈과의 결합도가 낮은채로 유지해서 앱에서 자주 사용되는 코드들을 편리하게 사용하게 해줘야 한다.

3-도메인 지식에 따른 분리 기준

-단순히 도메인 계층을 나누겠다는 의미보다는 도메인 단위로 나누라는 의미이다.

-즉, 비즈니스적으로 의미가 있는 단위로서 모듈을 나누는 것이 좋다. 각각의 모듈이 비즈니스의 시스템을 나타내야 한다. 단순히 feature 별로 기능을 나눈다면 너무 많은 모듈로 세분화되어서 코드를 관리하는데 어려움이 있다.

-각각의 모듈 하나하나가 시스템이라고 생각하고 어떻게 정의 할 수 있을지에 대해서 생각해보아야 한다.

-feature는 사실상 시스템간 상호작용하는 과정중에서 흩어져 있어야 더 적절하다.

멀티모듈 시 주의사항

1-

-하나의 모듈이 너무 많은 역할을 한다면 더 분리해줘야 한다.

2-

-하나의 모듈이 오직 하나의 플레이어에 의해서 사용된다면 굳이 모듈로 분리시킬 필요가 없고 그 플레이어에 넣어주면 된다.

3-

-단순히 모듈이 엄청 크다고 모듈을 세분환하는 것처럼 모듈의 규모에 따른 기준으로 모듈을 분리해서는 안된다.

모듈을 나누는 기준 총정리

-도메인 지식

• 하나의 모듈은 그룹화가 될 만큼 명확한 분량의 도메인 지식을 캡슐화한 상태로 가지고 있어야 한다.(주의!!피쳐기준이 아니야!!)

-잘 정의된 범위

• 좋은 범위는 새로운 기능 조각이 하나의 모듈에 속할지 그렇지 않을지를 애매모호하지 않게 해줘야 한다.
  

• 새로운 feature가 이 모듈에 포함해도 될 지 말지에 대한 것이 애매모호하게 이루어져 있으면 안된다.

-재사용성

• 모듈이 제공하는 기능은 여러 종류의 앱에서 사용될 수 있어야 한다.

-선택 가능성

• 모듈이 제공하는 기능은 특정 앱에서 활성화 될 수도 있고 아닐 수도 있다.

• 모바일에서는 사용되고 웨어러블에서는 사용되지 않는 이런 식으로 선택적으로 해당 모듈을 사용 할 수 있게 해야한다.

-의존성 관리

• 새로운 모듈은 기존 모듈과 확연히 다른 의존성 요구사항을 갖느다.

-책임조직

• 장기간 이 모듈을 책임질 의지가 있는 팀이 존재한다. 즉, 일단 모듈이 나뉘어졌다면 해당 모듈을 책임질 담당자가 있어야 한다.

모듈을 나눠야 하는 적절한 시기

-오늘부터 나누는것이 제일 좋다. 모듈을 나누는데 있어서 굉장히 많은 시간과 노력이 들어가기 때문에 만약 시간이 흘러서 프로젝트의 규모가 커지면 커질수록 더 많은 시간과 노력이 들어가야 하기 때문에 웬만하면 빨리 진행하는 것이 더 좋다.