19959a2b3f
Introduces the first versions of client and staff mobile application prototypes, including platform-specific assets, screens, and configuration for Android, iOS, macOS, Linux, and Windows. Adds documentation, AI prompt guides, and a new staff payments feature module with repository, use cases, and presentation logic. Also includes generated localization files and supporting resources for both client and staff apps.
89 lines
2.7 KiB
Markdown
89 lines
2.7 KiB
Markdown
Task is to refactor the **domain and data layers** of an existing feature so that they fully comply with the architecture rules defined in:
|
|
|
|
* `apps/mobile/docs/01-architecture-principles.md`
|
|
|
|
## 📍 TARGET FEATURE
|
|
|
|
Feature to refactor:
|
|
|
|
```
|
|
apps/mobile/packages/features/staff/payments
|
|
```
|
|
|
|
Files exist in:
|
|
|
|
```
|
|
lib/src/domain/
|
|
lib/src/data/
|
|
```
|
|
|
|
## 🏆 GOLD STANDARD REFERENCE
|
|
|
|
Use the following feature as the **gold standard implementation** for structure, responsibility split, and dependency direction:
|
|
|
|
```
|
|
apps/mobile/packages/features/staff/authentication
|
|
```
|
|
|
|
Follow its patterns for:
|
|
|
|
* Repository interfaces
|
|
* Use case design
|
|
* Data layer delegation
|
|
* Interaction with `apps/mobile/packages/data_connect`
|
|
|
|
## 🎯 GOAL
|
|
|
|
Refactor the feature so that its **Domain** and **Data** layers strictly follow **KROW Clean Architecture** as defined in `apps/mobile/docs/01-architecture-principles.md`.
|
|
|
|
The feature must rely on **shared Domain entities** and must delegate all data access through `apps/mobile/packages/data_connect`.
|
|
|
|
## STRICT RULES (NON-NEGOTIABLE)
|
|
|
|
You MUST follow **all rules defined in**:
|
|
|
|
* `apps/mobile/docs/01-architecture-principles.md`
|
|
|
|
In particular, ensure that:
|
|
|
|
* Domain uses **only entities from**:
|
|
|
|
```
|
|
apps/mobile/packages/domain/lib/src/entities
|
|
```
|
|
* Feature-level domain models are removed
|
|
* Repository interfaces live in the Domain layer
|
|
* Repository implementations live in the Data layer
|
|
* Domain does NOT return concrete data objects
|
|
* Usecases in the domain layer must be extended from the `apps/mobile/packages/core/lib/src/domain/usecases/usecase.dart`.
|
|
* If there are arguments in the usecases, they must be extended from the `apps/mobile/packages/core/lib/src/domain/arguments/usecase_argument.dart`. Example usecase is given below
|
|
- `apps/mobile/packages/features/staff/authentication/lib/src/domain/usecases/verify_otp_usecase.dart`
|
|
* Data layer does NOT contain business logic and not create objects only call the `apps/mobile/packages/data_connect`.
|
|
* All data access flows through `apps/mobile/packages/data_connect`
|
|
|
|
## DOCUMENTATION
|
|
|
|
* Add clear **doc comments** to all files you modify
|
|
* Document:
|
|
* Purpose of the file
|
|
* Role of the class or interface in the architecture
|
|
|
|
## SAFETY GUARANTEES
|
|
|
|
* Do NOT change existing behavior
|
|
* Do NOT break presentation layer contracts
|
|
* Do NOT bypass `apps/mobile/packages/data_connect`
|
|
|
|
## EXPECTED OUTPUT
|
|
|
|
* Domain layer aligned with `apps/mobile/docs/01-architecture-principles.md`
|
|
* Data layer aligned with `apps/mobile/docs/01-architecture-principles.md`
|
|
* Structure and patterns consistent with:
|
|
|
|
```
|
|
apps/mobile/packages/features/staff/authentication
|
|
```
|
|
* Clean, documented, and compliant implementation
|
|
|
|
Proceed with the refactor now.
|