E-Commerce Class Diagram

An online shop needs a small set of core types: customers, orders, the lines inside an order, products and payments. This UML class diagram shows those classes, their fields and methods, and how they relate: who owns whom, how many of each, and which classes inherit from a common parent.

It is the model a team agrees on before writing the code and the database tables.

1. The Diagram

Online shop domain model Customer - id: UUID - email: String - name: String + placeOrder(cart): Order Order - id: UUID - placedAt: Instant - status: OrderStatus + total(): Money + cancel(): void OrderLine - quantity: int - unitPrice: Money + subtotal(): Money Product - sku: String - name: String - price: Money + isInStock(): bool «enumeration» OrderStatus CREATED PAID SHIPPED DELIVERED CANCELLED {abstract} Payment - amount: Money - paidAt: Instant + authorize(): bool CardPayment - last4: String - network: String + authorize(): bool PayPalPayment - payerId: String + authorize(): bool BankTransfer - iban: String + authorize(): bool 1 0..* places 1 1..* 0..* 1 refers to 1 0..* paid by «use»
  1. Customer 1 to 0..* Order: one customer can place zero or more orders; each order belongs to exactly one customer.
  2. Order to OrderLine (filled diamond): composition. Lines cannot exist without their order; delete the order and its lines go too. Every order has at least one line (1..*).
  3. OrderLine to Product (arrow): a navigable association. A line knows its product, but a product does not keep a list of every line that ever sold it. The line copies unitPrice so later price changes do not rewrite old orders.
  4. Order to Payment 0..*: an order may have no payment yet, or several (for example a gift card plus a card).
  5. Payment hierarchy: Payment is abstract (italic name), and its authorize() is abstract too. Each subclass adds its own fields and implements authorize(); the hollow triangle points to the parent.
  6. OrderStatus is an enumeration; the dashed arrow says Order depends on it.

2. How to Read It

Notation used ClassName - attribute: Type + operation(): Type name / attributes / operations + public - private # protected association (with multiplicities) navigable association composition: part dies with whole aggregation: shared part generalization (inherits) dependency (uses)

Multiplicities sit at the far end of a line: read Customer places 0..* Order from left to right. The diamond always sits on the whole side of a whole-part relation.

3. Variant: Object Diagram Snapshot

One real order as objects c42 : Customer email = "ana@example.com" o1001 : Order status = PAID placedAt = 2026-09-30 l1 : OrderLine quantity = 2 unitPrice = 19.99 l2 : OrderLine quantity = 1 unitPrice = 45.00 p7 : Product sku = "MUG-01" p9 : Product sku = "TEE-L" pay3 : CardPayment amount = 84.98 last4 = "4242" Check: 2 x 19.99 + 1 x 45.00 = 84.98, the amount on pay3.

An object diagram uses the same boxes but with underlined name : Type and real values. It is a quick way to test a class diagram: if you cannot draw a believable snapshot with it, the model is wrong. Here the amounts add up, and the snapshot obeys every multiplicity in the class diagram.

4. Pros and Cons

Pros

Cons

5. When to Use It

Use it when

Skip it when

6. As Diagrams-as-Code

The main diagram written for Mermaid:

classDiagram
    class Customer {
        -UUID id
        -String email
        -String name
        +placeOrder(cart) Order
    }
    class Order {
        -UUID id
        -Instant placedAt
        -OrderStatus status
        +total() Money
        +cancel() void
    }
    class OrderLine {
        -int quantity
        -Money unitPrice
        +subtotal() Money
    }
    class Product {
        -String sku
        -String name
        -Money price
        +isInStock() bool
    }
    class Payment {
        <<abstract>>
        -Money amount
        -Instant paidAt
        +authorize()* bool
    }
    class OrderStatus {
        <<enumeration>>
        CREATED
        PAID
        SHIPPED
        DELIVERED
        CANCELLED
    }
    Customer "1" -- "0..*" Order : places
    Order "1" *-- "1..*" OrderLine
    OrderLine "0..*" --> "1" Product : refers to
    Order "1" -- "0..*" Payment : paid by
    Order ..> OrderStatus
    Payment <|-- CardPayment
    Payment <|-- PayPalPayment
    Payment <|-- BankTransfer

Mermaid writes the type before the name for fields. In PlantUML the same model reads class Order { -id: UUID } and Order "1" *-- "1..*" OrderLine.