core 에 모든 종류의 데이터가 한 곳에 담아져서 관리되기 때문에 극도로 작은 관심사를 가진 feature 에서 불필요한 의존성을 가지게 됩니다.
e.g) feature:setting 모듈은 SettingsRepository 만 필요하지만 해당 data-api 모듈에는 contributor, session, sponsor 접근자가 함께 있어 각 관심사에 맞게 종단으로 분리해줄 필요가 있습니다.
이는 대형 서비스에서는 서비스단위, 조직단위로 별도로 관리가 용이해지기때문에 확장성과 유연성을 확보한 app-modularisation 방법입니다.
관심사 분리 장점
위에서 예시를 든 feature:setting 과 core:datacore:model 에서 SettingRepository 관련 부분을 core:setting 으로 분리하게 되면 contributor, session, sponsor 에 대한 의존성이 사라지게 되어 코드 변경으로부터 자유로워집니다.
이와 같은 관리 대상이 거대한 단위로 바뀌게 되면 언제든 별도의 저장소나 아카이빙 형태로 분리하여 관리가 용이합니다
관심사 분리 단점
모듈이 매우 많아질수 있습니다.
모듈이 많아지기에 의존성 관리를 철저히 하지 않으면 오히려 빌드 효율성을 떨어뜨릴 수 있습니다.
의견
다중 모듈화 예시로 데이터레이어, 도메인레이어, 피쳐레이어 등등을 얘기하나 이는 횡단 관점에서만 해당되며 종단 관점에서도 다중 모듈화를 염두한 설계가 필요하기에 이 작업이 적절한 예시가 될것이라 생각합니다.
관심사 분리
feature:setting
모듈은SettingsRepository
만 필요하지만 해당data-api
모듈에는contributor
,session
,sponsor
접근자가 함께 있어 각 관심사에 맞게 종단으로 분리해줄 필요가 있습니다.관심사 분리 장점
feature:setting
과core:data
core:model
에서SettingRepository
관련 부분을core:setting
으로 분리하게 되면contributor
,session
,sponsor
에 대한 의존성이 사라지게 되어 코드 변경으로부터 자유로워집니다.관심사 분리 단점
의견
다중 모듈화 예시로 데이터레이어, 도메인레이어, 피쳐레이어 등등을 얘기하나 이는 횡단 관점에서만 해당되며 종단 관점에서도 다중 모듈화를 염두한 설계가 필요하기에 이 작업이 적절한 예시가 될것이라 생각합니다.