Skip to content

Latest commit

 

History

History
86 lines (80 loc) · 4.72 KB

e_commerce_feature_architeccture.md

File metadata and controls

86 lines (80 loc) · 4.72 KB

Here is the proposed architecture for the cart, payments, and orders features.

  1. Cart Feature (lib/features/cart) Since this will run locally for now, we'll use a local data source. This is a great example of how Clean Architecture allows you to swap out data sources (e.g., from local to remote) without changing your business logic or UI.

Domain Layer: Entities: CartItemEntity: Will hold a ProductEntity and the quantity. This is crucial; the cart doesn't store product details itself, it just references the product and adds its own specific data (quantity). CartEntity: Represents the entire cart, containing a list of CartItemEntity and calculated properties like totalPrice. Repository Interface (CartRepository): Future<Either<Failure, CartEntity>> getCart() Future<Either<Failure, void>> addProductToCart(ProductEntity product) Future<Either<Failure, void>> removeProductFromCart(String productId) Future<Either<Failure, void>> updateQuantity(String productId, int newQuantity) Use Cases: A use case for each repository method (e.g., GetCartUsecase, AddProductToCartUsecase). Data Layer: Data Source (CartLocalDataSource): This will be an abstract class. The implementation (CartLocalDataSourceImpl) will manage a list of cart items in memory for now. Later, we could easily switch this to use isar for local persistence across app sessions. Repository Impl (CartRepositoryImpl): Implements the CartRepository interface. It will call the CartLocalDataSource to perform operations. Presentation Layer: BLoC (CartBloc): Manages the state of the shopping cart (CartState which will hold the CartEntity). Handles events like ProductAdded, ProductRemoved, QuantityUpdated. UI ( CartPage ): Subscribes to the CartBloc to display the list of CartItemEntity. Allows users to change quantities or remove items. Shows the total price and a "Proceed to Checkout" button. How ProductDetailsPage interacts with Cart : The "Add to Cart" button on your ProductDetailsPage will not talk to the CartBloc directly. Instead, it will call the AddProductToCartUsecase via a provider. This keeps the features decoupled. The CartBloc will then react to the data change and update the UI across the app (e.g., a cart icon with a badge).

  1. Payments Feature (lib/features/payments) This feature is responsible for handling the transaction itself.

Domain Layer: Entities: PaymentMethodEntity: (e.g., 'Cash on Delivery', 'Online'). TransactionEntity: Represents the result of a payment attempt. Repository Interface (PaymentRepository): Future<Either<Failure, void>> processPayment(CartEntity cart, PaymentMethodEntity method) Use Cases: ProcessPaymentUsecase. Data Layer: Data Source (PaymentRemoteDataSource): The implementation will connect to a payment gateway SDK (like Razorpay, Stripe) for online payments or simply return a success state for "Cash on Delivery". Presentation Layer: UI (CheckoutPage / PaymentPage): This page is shown after the user clicks "Proceed to Checkout" from the CartPage . It will display the order summary (from the CartEntity). It allows the user to select a payment method. The "Pay Now" button will trigger the ProcessPaymentUsecase. 3. Orders Feature (lib/features/orders) This feature handles the result of a successful payment: creating an order and viewing past orders.

Domain Layer: Entities: OrderEntity: Contains an order ID, list of items, total amount, status (e.g., 'Pending', 'Shipped'), date, etc. Repository Interface (OrderRepository): Future<Either<Failure, OrderEntity>> createOrderFromCart(CartEntity cart) Future<Either<Failure, List>> getMyOrders() Use Cases: CreateOrderUsecase, GetMyOrdersUsecase. Data Layer: Data Source (OrderRemoteDataSource): The implementation will make API calls to your backend to save the order and fetch the order history. Presentation Layer: BLoC (OrderBloc): Manages fetching and displaying the list of past orders. UI: OrderConfirmationPage: Shown after a successful payment. OrderHistoryPage: A list of all past orders (likely a new screen accessible from the "Profile" tab). OrderDetailsPage: Shows the details of a single past order. Summary of the Flow: Product Details -> cart feature: User taps "Add to Cart" -> AddProductToCartUsecase is called. Cart Page -> payments feature: User taps "Checkout" -> App navigates to CheckoutPage. Checkout Page -> orders feature: User taps "Pay Now" -> ProcessPaymentUsecase is called. On success, it triggers the CreateOrderUsecase. Profile -> orders feature: User taps "My Orders" -> GetMyOrdersUsecase is called to display the order history. This architecture ensures each feature is self-contained and responsible for one thing, but they can communicate effectively through their domain layers.

Does this architectural plan align with your vision? We can start by building the cart feature first.