Overview › Architecture & Module Structure

Architecture & Module Structure

Strong modular layout, clean MVVM, repository pattern adopted at scale.

0 findings in this category

SCORE

Summary

The codebase follows a clear modular architecture with one app module (Costco), 22 feature modules, 30 shared modules, and 3 core/library modules. Most feature modules adhere to a presentation / domain / data layering, with strong adoption of MVVM and the repository pattern.

Strengths

PASS

Modular feature decomposition

Features are independently buildable Gradle modules, enabling parallel development and clean ownership boundaries (account, dmc, productdetaillanding, warehouse, nativehome, etc.).

PASS

Repository pattern at scale

~190 *RepositoryImpl classes implement repository interfaces, decoupling data access from ViewModels.

feature/productdetaillanding/src/main/java/com/costco/app/productdetaillanding/repo/ProductDetailPageLandingRepositoryImpl.kt

PASS

UseCase / Domain layer

UseCase implementations (BffUseCaseImpl, SdUiUseCaseImpl, NativeSearchUseCaseImpl) sit between ViewModels and repositories, isolating business rules.

Findings

MEDIUM

App module still hosts feature logic

The Costco app module contains domain code (Pharmacy, ShoppingList, FindAStore, customer service) that should be extracted to feature modules to match the rest of the architecture.

Costco/src/main/java/com/costco/app/android/ui/pharmacy/Costco/src/main/java/com/costco/app/android/ui/main/MainActivity.java

Recommendation: Extract Pharmacy, ShoppingList, FindAStore into feature/* modules; the app module should only host navigation, DI wiring, and Application class.

MEDIUM

Inconsistent layering between feature modules

Some features have a clean presentation/domain/data split (productdetaillanding, nativesearch); others mix layers under flatter ui/repo/ structures.

Recommendation: Establish a module template (with a Gradle convention plugin) enforcing the same package structure and module dependencies across features.

LOW

30 shared modules — risk of fragmentation

Shared module count is high (auth, bff, blankutil, common, commonui, contentstack, data, designtoken, exception, featurehelper, featuresearch, geofence, grs, lucidworks, model, notification, pallet, sdui, statemanagement, storage, topbar, translation, ui, util, ...). Several look adjacent (common vs commonui vs ui; util vs blankutil).

Recommendation: Run a dependency-graph audit (./gradlew :module:dependencies + moduleGraph) and merge or rename redundant shared modules.

INFO

Convention plugins worth introducing

With 56 build files, drift between modules is inevitable. A buildSrc/build-logic convention plugin would centralize SDK versions, Kotlin compile options, Hilt setup, and test configuration.

Architectural Health

Aspect	Status	Notes
MVVM consistency	PASS	37+ `@HiltViewModel` classes
Repository pattern	PASS	190+ implementations
UseCase layer	PASS	Present in major features
App module purity	MEDIUM	Still owns Pharmacy, ShoppingList
Module conventions	MEDIUM	No build-logic / convention plugin found
Single source of truth	LOW	30 shared modules; some overlap

Costco Android · Code Review Report · Generated 2026-05-07 · 626 machine-curated findings