기능 단위의 분리를 원칙으로 한다.
모듈 및 디렉토리 분리는 철저하게 기능(domain) 단위를 기준으로 삼도록 한다.
기능 단위로 모듈을 분리해야한다는 의견은 마틴 파울러를 레퍼런스로 한다.
Layer 단위의 모듈 분리를 하게 된 이유
여기서 모듈로 분리되는 domain 모듈이란, 안드로이드 공식 문서의 도메인 레이어 를 뜻한다.
Layer 단위의 모듈 분리를 허용하게 된 이유는 다음과 같다.
1. "JUnit5" 를 활용해서 "바닐라 코틀린" 모듈을 만들고 싶다.
지금 안드로이드에서는 JUnit4 를 지원한다.
JUnit5 환경에서 개발을 하고 싶다면, 별도 모듈로 분리를 해야한다.
종래의 app 모듈은 어떻게든 안드로이드에 종속적일 수 밖에 없다.
다만 domain 에는 안드로이드에 종속적이지 않은 로직으로 구현이 되어야한다.
초짜 개발자라는 것을 감안하여 의식적인 훈련을 위해서, 일부러 분리를 하도록 하자.
2. git 을 사용하는데 있어서 conflict 를 미연에 방지한다.
로직 및 데이터와 관련된 이슈와, 화면에 보여지는 UI 와 관련된 이슈를 철저하게 분리하고 싶다.
그리고 그렇게 분리된 이슈를 작업해서 PR 을 보내는데 있어서 conflict 를 미연에 방지하고 싶다.
conflict 방지에 있어서는 기능 단위의 분리가 제일 효과적이지만,
conflict 와 함께 안드로이드 팀원들이 UI, Domain, Data 를 의식적으로 분리를 했으면 좋겠다.
그런 의미에서 추후에 Data 또한 별도의 모듈로 분리를 해볼까 한다.
domain 모듈 내부의 디렉토리 구조는 어떻게?
다음과 같은 가이드라인을 시도해보도록 하자.
Core vs Cross-Cutting
기능 혹은 도메인 단위를 기준으로 분리하는 것을 핵심관심모듈 (Core concern, Vertical) 이라하고,
Layer 혹은 생명주기를 단위로 공통로직을 분리하는 것을 부가관심모듈 (Cross-Cutting concern, Horizontal) 이라고 하는 것 같다.
주의사항
분리는 신중하게 하도록하자.
잘못된 분리를 다시 합치는 비용은 비싸기 떄문이다.
패키지, 모듈, 서비스 등 물리적 단위의 분리는 정말 필요할 때까지 아껴야 한다.
절대로 하지 말아야 할 설계
공통적으로 쓰이는 로직을 common 혹은 util 혹은 library 라는 이름의 모듈로 분리하지 않도록 한다.
이유는 우아한 형제들 기술 블로그의 공통(Common) 모듈의 저주 를 참고해서 읽도록한다.
