// the find
AhmedLSayed9/deliverzler
Delivery App for Restaurants built on Flutter using Domain-Driven Design (DDD) and Layered Architecture along with Riverpod Framework.
A Flutter delivery driver app for restaurants, showing how to structure a real-world Riverpod project with DDD layered architecture. It's a reference implementation more than a production-ready product — Firebase is the backend, and the admin side (user management, order creation) is explicitly out of scope. Best suited for Flutter developers who want to see DDD and Riverpod 2.0 with code generation applied to a non-trivial domain.
The architecture is genuinely well-organized: feature-first folders with explicit presentation/domain/infrastructure layers, and the directory tree is consistent enough that you can predict where anything lives. The decision to use Riverpod's AsyncError propagation instead of Result/Either types cuts real boilerplate without sacrificing error visibility. Live tracking is implemented thoughtfully — the 5s+50m debounce on location updates avoids hammering Firestore, and new session tokens per Places search session is a nice cost-control detail. Three separate branches (main DDD, clean-arch with codegen, clean-arch without) let you compare the same problem solved different ways, which is useful for learning.
Firebase lock-in is total: auth, Firestore, Storage, FCM, Cloud Functions — swapping any of it out would require gutting the infrastructure layer. The setup friction is high for a reference project: you need a Firebase project, manually added auth users, a billing-enabled Google Maps project, and correctly named config files before you can run anything. No web support and the README doesn't mention it, so Flutter Web developers get nothing here. Test coverage is thin relative to the TDD branding — the clean-arch branch claims TDD but the main branch has unit tests only for select pieces, and there's no CI badge showing they actually pass.