Domain_Model

Domain Model

Our domain model contains seven classes and two enumerations. All classes are enclosed in a composition relationship with the main application class (not shown). Key decisions:

To promote artworks on premise, we would query the system for a list of artworks satisfying an onPremise attribute, instead of having someone with adminsitrator priviledges choosing promoted artwork. This reduces complexity of the model.

We decide to make no distinction between customers, artists, and users. Everyone can see the profile of everyone else. The same user can buy artwork and sell artwork with the same account. This improves user experience.

Furthermore, we decided to not have a separate class for artist profiles because profiles can be appropriately stored in User instances in the form of a profile picture and bio.

The shopping cart is abstracted away to its own class. This allows us to persist the shopping cart with its associated total price more easily.

The system should contain shipment details and order status. This will be useful in later sprints for finite state machine implementations.

It is not necessary that a payment be associated with each order, since one can place an order with a PaymentPending status while the payment information is not fully set up.

We will allow artists to see a list of artworks they have sold, so artwork sold is not deleted from the database. Instead, it is simply marked as sold through an artworkSold attribute, and we will not display them to the public.

• The User class is capable of acting as both a customer and/or an artist. This allows Artists to purchase paintings from a same account as that where they publicize their art.