How aviirajsharma/elitemart works
1. Overall shape
- This is a multi-module Android shopping app organized around Clean Architecture + MVVM.
- The codebase is split into three main layers: presentation, domain, and data. The root Gradle setup wires them together.
2. Presentation module = app entry + UI
- presentation/ contains the Compose UI, ViewModels, navigation, theming, and Android entry points.
- Key app entry classes are MainActivity, ShopperApp, and ShopperSession.
- Screens are grouped by feature: login/register, home, all products, product details, cart, cart summary, orders, profile, and user address.
3. Presentation state and navigation
- Each feature screen has a matching ViewModel, which is the state-holder and orchestrator for that screen.
- Navigation is handled with Compose Navigation, with route definitions in navigation/.
- There are custom nav types/wrappers for passing complex objects like product data and user address between screens.
4. Domain module = business rules
- domain/ is the core business layer and is intentionally free of Android/UI concerns.
- It defines:
- repository interfaces for cart, categories, orders, products, and users
- use cases for each business action
- domain models for products, cart, categories, orders, user, and address
- a network service interface used as a boundary to remote data access
5. Use case layer
- The use cases are the primary entry points from ViewModels into business logic.
- They cover the app’s main actions: login, register, fetch products/categories, add to cart, update quantity, get cart, cart summary, place order, list orders, and delete product.
- This makes the dependency direction clear: UI never talks to repositories directly.
6. Data module = remote data access
- data/ contains the concrete implementations of the repository interfaces.
- NetworkServiceImpl is the implementation that talks to the backend API.
- Repository implementations transform remote DTOs into domain-friendly models and expose them to the domain layer.
7. Data contracts and model boundaries
- The repo distinguishes three model layers:
- data models / DTOs in data/model
- domain models in domain/model
- UI models in presentation/model
- This indicates explicit mapping boundaries between API payloads, business objects, and screen-specific state.
8. Feature flow through the app
- Typical flow is: Compose screen → ViewModel → Use Case → Repository interface → Repository implementation → Network service → REST API.
- Responses then flow back through mapping layers into domain objects and finally into UI state.
- The app is heavily network-driven; there is no obvious local database layer in the tree.
9. Backend/API boundary
- The architecture expects a remote HTTP/REST backend and internet access.
- The README calls out Ktor client, though the tree only shows the abstraction/implementation split, not the transport details.
- The main external dependency boundary is therefore the shopping API for products, auth, cart, orders, and addresses.
10. Dependency injection
- DI is organized per layer:
- data/di
- domain/di
- presentation/di
- These modules likely bind repository implementations, use cases, and ViewModels into the app graph.
- The README mentions Koin, and the module structure matches that style of layered injection.
11. User/session concerns
- ShopperSession suggests a lightweight session/auth state holder in the presentation layer.
- Login and registration are first-class flows, so user identity/auth state is a core cross-screen concern.
12. Main architectural boundaries to show in a diagram
- Strong boundary between UI/state and business logic.
- Strong boundary between domain interfaces and data implementations.
- Strong boundary between app models and API DTOs.
- External boundary is the remote shopping backend accessed through the network service layer.
13. Testing footprint
- The repo includes unit and instrumented tests in each module, plus a specific CartViewModelTest.
- That suggests the cart flow is an important stateful path and the architecture is designed to be testable at layer boundaries.
Main entry points: feature ViewModels · repository Repository Impl · usecase Use Cases · NetworkServiceImpl.kt NetworkServiceImpl
Components 18
Presentation
Compose UI, navigation, session, and feature ViewModels
- MainActivity · Android app entry point
presentation/src/main/java/com/cscorner/elitemart/MainActivity.kt - ShopperApp · Top-level Compose host and app wiring
presentation/src/main/java/com/cscorner/elitemart/ShopperApp.kt - ShopperSession · Lightweight session/auth state holder
presentation/src/main/java/com/cscorner/elitemart/ShopperSession.kt - Nav Routes · Screen routes and navigation graph definitions
presentation/src/main/java/com/cscorner/elitemart/navigation/NavRoutes.kt - Feature UI · Login, home, products, cart, orders, profile, and address screens
presentation/src/main/java/com/cscorner/elitemart/ui/feature - ViewModels · Screen-level state and orchestration for each feature
presentation/src/main/java/com/cscorner/elitemart/ui/feature - UI Models · Screen-specific models such as product and user address
presentation/src/main/java/com/cscorner/elitemart/model - Presentation DI · Presentation-layer dependency bindings
presentation/src/main/java/com/cscorner/elitemart/di/PresentationModule.kt
Domain
Business rules, repository contracts, models, and use cases
- Domain Models · Core business models for products, cart, orders, users, and address
domain/src/main/java/com/cscorner/domain/model - Repo Contracts · Repository boundaries for cart, categories, orders, products, and users
domain/src/main/java/com/cscorner/domain/repository - Network Boundary · Domain-facing network service abstraction
domain/src/main/java/com/cscorner/domain/network/NetworkService.kt - Use Cases · Login, register, fetch, cart, order, and delete flows
domain/src/main/java/com/cscorner/domain/usecase - Domain DI · Domain-layer dependency bindings for use cases and contracts
domain/src/main/java/com/cscorner/domain/di/DomainModule.kt
Data
Repository implementations, DTOs, and network access
- DTO Models · Remote request and response models
data/src/main/java/com/cscorner/data/model - NetworkServiceImpl · Concrete remote API access implementation
data/src/main/java/com/cscorner/data/network/NetworkServiceImpl.kt - Repository Impl · Transforms DTOs into domain-friendly data and fulfills repository contracts
data/src/main/java/com/cscorner/data/repository - Data DI · Data-layer dependency bindings for network and repositories
data/src/main/java/com/cscorner/data/di/DataModule.kt
External
Remote shopping backend
- Shopping API · External REST backend for auth, catalog, cart, orders, and address
Connections 22
- MainActivity → ShopperApp: launches · Activity starts the Compose app shell
- ShopperApp → Nav Routes: hosts · App shell owns navigation and screen routing
- Nav Routes → Feature UI: navigates · Routes connect to feature screens
- Feature UI → ViewModels: reads state · Screens observe and send events to ViewModels
- ViewModels → Use Cases: invokes · ViewModels call business actions through use cases
- ViewModels → UI Models: maps to · Presentation converts domain data into screen models
- ShopperSession → ViewModels: shares auth · Session state is consumed by feature state holders
- Presentation DI → ViewModels: wires · Presentation DI provides ViewModels
- Presentation DI → ShopperApp: configures · Presentation DI supports app setup
- Use Cases → Repo Contracts: depends on · Business logic depends on repository contracts only
- Use Cases → Domain Models: returns · Use cases operate on domain models
- Domain DI → Use Cases: wires · Domain DI assembles use case graph
- Repo Contracts → Network Boundary: abstracts · Repository contracts sit above the service boundary
- Repository Impl → Repo Contracts: implements · Concrete repositories fulfill domain contracts
- Repository Impl → DTO Models: maps · Repository implementations transform DTOs
- NetworkServiceImpl → Shopping API: calls · HTTP client talks to remote shopping backend
- Repository Impl → NetworkServiceImpl: uses · Repositories fetch data through the network service implementation
- Data DI → Repository Impl: wires · Data DI binds repository implementations
- Data DI → NetworkServiceImpl: wires · Data DI binds network implementation
- NetworkServiceImpl → Network Boundary: conforms to · Concrete network service satisfies the domain boundary
- DTO Models → Domain Models: maps into · Remote payloads are converted into domain objects
- UI Models → Domain Models: derived from · Screen models are projected from domain data