Webshop Cart

For my work at Liones I am writing a technical design for a shopping cart. The requirements are fairly basic, except for one: the shopping cart must be generic to support any payment service provider (psp) and customer relationship management (CRM) system. Also there might be several different product types in the future, like: subscriptions, downloads, pay per use, etc.. These requirements make the shop very complex and a great challenge.

I started with an investigation on the internet about this subject and I quickly found out that there aren’t much articles on this topic around, but I found a few very interesting ones though. Next I started to draw some UML diagrams; I added some best practices like the Money class.

Then it got interesting: Yvonne (a colleague, senior/lead developer) and I were going over my conceptual model and we were adding and shifting responsibilities as we were going. Things went rapid from that point on: object came to the surface, responsibilities were put on the right place and the domain model started to reveal itself.

The next thing we did was to group objects into packages and again there was some debate about in which package we would put certain objects and what the dependencies between the packages were. The debates made the domain model even clearer. We came up with the following packages:

  • Product Catalog (Product information and grouping)
  • Cart (The actual cart)
  • Payment Service (Encapsulation of different payment service providers)
  • CRM (synchronization with back office)
  • User (User & Profile)

I am not going to discuss the packages in detail here because that is not the scope of this post.

Once we wrapped up that session, I drew the new UML diagrams (in Sparx Enterprise Architect). I made some minor refinements in the model and I set up a meeting with Yvonne and Gjalt (another colleague, architect) to review the technical design.

As the review session went on, we made a few minor refinements on the design and discussed how certain parts could be implemented. There was one major element that wasn’t clear: how does the coupling with a payment service provider work? There seem to be 2 categories: synchronous payments and asynchronous payments.

That is where we stand now, we brainstormed on how to tackle the payment problems but that is for part 2!

Share and Enjoy:
  • Print
  • Twitter
  • LinkedIn
  • Digg
  • DZone
  • del.icio.us
  • Google Bookmarks
  • StumbleUpon
  • Technorati