My previous thread "Kudos, Issue Tracking & Project Architecture" was void of the architecture topic that I had intended to present, so I'll start the discussion here in this new thread...
I'll start by sharing a bit about myself. In my real job (aka day job) I provide technical and design support for enterprise purchasing applications, with our current system built upon a product developed by SAP (unfortunately our requirements have required significant customization to the base product). Those who have worked with SAP applications will have recognized that they are very far from technical beauty, but there are certainly very good conceptual design concepts that can be borrowed and/or learned from. In this case I am speaking of the modularization of specific business functions into configurable components that can be assembled in different ways using provided APIs. This has actually evolved into the latest corporate buzz known as Service Oriented Architecture (SOA), but I'm getting off track... (sorry)
Anyways, I feel that there is a really good opportunity to increase the value of this new DNN Store module by further modularizing this module's capabilities into smaller components... thus I am posting these thoughts here to share with project team and other interested community members
Concept: Abstraction and/or separation of Catalog and Shopping Cart store components.
Purpose: Provide enhanced business capabilites for DNN Store project through provision of flexible and extensible function-specific components
Description:
-> Separate DNN Store module into two conceptual components: Catalog and Shopping Cart (would not necessarily require separate PA)
-> DNN Catalog component provides capabilities for display/management of products, categories and collaboration (user reviews, email to friend, cross-sell, etc...)
-> DNN Shopping Cart (or perhaps "Order Management") component provides shopping cart, payment gateway and other future enhancements (perhaps shipping calculation, tax engine, etc)
-> DNN Catalog uses "shopping cart provider" model to allow interaction with different shopping cart systems
-> DNN Shopping Cart provides API to receive line items from different catalog systems.
-> Catalog and Shopping Cart components can be used together or configured to 3rd-party components using custom provider and provided API
Scenario 1 - "Classic" DNN Store
Identical in functionality to DNN Store 01.00.00 with catalog, cart, payment and order management functions all provided via standard DNN components
DNN Catalog -> [DNN cart Provider] -> [DNN Cart API] -> DNN Shopping Cart -> [PaymentProvider] -> Payment Gateway (PayPal, etc)
Scenario 2 - Alternate Shopping Cart
In this example, PayPal Shopping Cart API could be used to provide more-basic cart/gateway solution that does not require DNN user registration or address maintenance. Order management occurs within paypal application.
DNN Catalog -> [PayPal Cart Provider] -> [PayPal Cart API] -> PayPal Cart/Gateway
Scenario 3 - Alternate product catalog
This scenario provides ability to develop/utilize specialized product catalogs. For example, a photo album is enhanced to provide ability to order prints online... A specialized catalog application is used to market softare - something like SnowCovered... an online booking module allows users to reserve and pay for events. In any case, this scenario 3 depicts a 3rd-party DNN module communicating with the DNN cart an available API.
3rd-Party DNN Catalog -> [DNN Cart API] -> DNN Shopping Cart -> [PaymentProvider] -> Payment Gateway
Scenario 4 - External product catalog
This final scenario could be used to provide an API that allows other websites to submit items into a DNN cart, perhaps by placing a custom module on a hidden page. Why would you want this? I personally don't have the need, but this is something that is commonly known as "punch out" within enterprise purchasing systems like Ariba and SAP. In our case a DNN portal module is configured to direct the user ("punch out") to a preconfigured web site where he/she is able to shop from that supplier's catalog. When shopping is completed the external catalog uses HTTP to post the cart contents back to the origin system for purhcase order generation and/or payment. Probably not a huge need for this in DNN, but this is simply another example of capability that could be custom developed with provision of a 'DNN Cart API'.
External Web Site -> [HTTP protocol] -> Custom DNN Control/WebService -> [DNN Cart API] -> DNN Shopping Cart -> [PaymentProvider] -> Payment Gateway
Okay... so this might be considered a major change to the current project architecture, but let's at least consider that the current technical design is actually not that far off. The Catalog and Cart module controls are for the most part function specific already. The DNN Store team has already developed a paymentprovider model whose concepts might be reusable for a cartprovider. The Cart already has functions that are used to insert items - these could be wrapped into an API.
So I post this idea for community discussion and project team consideration.
Thanks,
Chris