Overview of the Search Module
masterDocument interface. The module also includes a pagination utility to facilitate passing pagination data to different interfaces.repository·master·Indexed 20 days ago
https://github.com/i-love-flamingo/flamingo-commerceAn e-commerce framework featuring a standard one-page checkout flow, a robust GraphQL-based state machine for order placement, and a comprehensive Cart module. It supports custom payment providers, multidelivery workflows, and complex tax calculation algorithms (Vertical and Horizontal). The system utilizes an immutable Cart aggregate and a Decorated Cart for product information, providing detailed pricing invariants for items, deliveries, and total cart calculations.
Document interface. The module also includes a pagination utility to facilitate passing pagination data to different interfaces.The Category Module manages the domain model for product categories, including category data (name, media, etc.) and category trees. It provides:
CategoryFilter (implementing the search filter interface) which is passed to the productSearchService. Any implementation of the product search service must be able to handle this filter to show products within a category.Dependencies:
product package (for productSearchService)search package (for pagination)Flamingo Commerce is a toolkit for building fast, flexible, and headless commerce applications. It is designed around modern architectural principles like Domain-Driven Design (DDD) and the 'Ports and Adapters' pattern to ensure maintainability and scalability.
Key features include:
Customer represents the legal entity of a single person and is primarily used to power 'my account' functionality.Sourcing is the logic used to determine the best possible location(s) from which a product or an ordered item should be fulfilled. It is used to allocate ordered items to source locations based on factors such as:
Common integration points include:
PlaceOrder adapter.Cart and CartItem with references to the underlying Product objects (via the dependency product package).CustomerIdentityOrderService port to fetch actual customer order data from your backend or database. You must implement this interface to bridge the module's domain model with your data source.The package distinguishes between two core concepts to manage payment processing:
PaymentRequest.The primary abstraction for implementing payment flows is the WebCartPaymentGateway interface.
To ensure a module is "runnable by default," it must provide FakeAdapters for its required secondary ports (interfaces used to communicate with external systems or infrastructure).
The RestrictionService allows you to enforce product limits (e.g., maximum quantities). You can add custom restrictions by using Dingo multibinding to the cart.MaxQuantityRestrictor interface.
The service is triggered during cart add or update operations. It consolidates all bound restrictors and returns the most restrictive RestrictionResult, which includes:
The Price module uses three primary value objects to handle monetary values and payments:
5€). Internally, it uses big.Float for high-precision calculations.Price with a specific Type. This is used to add semantic meaning to a value or to describe payments in different currencies (e.g., paying a 5€ value using 500 Loyaltypoints).Charge objects. This allows representing a single total value through multiple payment methods (e.g., paying 5€ via two charges: 2€ cash and 300 Loyaltypoints).The Checkout Controller manages the end-customer journey through several sequential actions:
skipReviewAction is true: Proceeds to EarlyPlaceOrder and redirects to Payment Action.skipReviewAction is false: Redirects to Review Action.EarlyPlaceOrder.EarlyPlaceOrder. If not, checks flow status and places the order, then redirects to Success Action.