This is my fist application in retail domain. Hence architecture might be weak and some use cases might be missing. This opens scope of future changes.
WeMart application is a three-tier application as shown in summary diagram. Architecture diagram is also attached in below comment posted along with DAO layer class diagram.
Three User roles are being supported and represented as 'Buyer', 'Seller' and 'Advisor'. However they needs to be accessed polymorphic way as they all represent a User. In other words, it is possible that a single user_id is granted or revoked with all or any of three roles.
Their Association with Product is also presented in DAO layer diagram. A seller and advisor are directly linked to product, however buyer is linked to subscription only.
Idea behind this design is to make Buyer perceive Subscription as Product Type with number of bought units, as its attribute or as single product depending on context.
Let us understand above para with examples.
If a seller is selling policy then he will perceive policy as single product and will set product doc and picture only once and will set buyable unit as MAX_LONG value. Each policy subscription will have some units but will be represented by single instance of subscription.
This perception changes with house. In this case single instance will represent one unique product. Hence buyable unit will be one and once subscribed, it will have buyable unit as zero. Here now single subscription with unit as one, is actually a product which is not put on sale by buyer yet.
If Buyer wishes to take up seller's role, he would like to see house as sellable product in seller's portfolio and at same time in his buyer's profile.
WeMart Architecture

Last edit: Sachindra 2014-03-06