UML Class Diagram — E-commerce Domain

What this diagram shows

A UML class diagram models the static structure of an e-commerce system, showing how core entities like Product, Order, Customer, and Payment relate to each other. It represents inheritance hierarchies (such as PhysicalProduct and DigitalProduct inheriting from Product), composition relationships (an Order containing LineItems), and associations with multiplicity constraints (one Customer can have many Orders, one Order contains many LineItems). The diagram documents attribute types and method signatures, making it a blueprint for how these domain objects interact before any code is written.

Key components

• Class Box — Represents a single entity with three sections: class name, attributes with types, and methods with signatures.
• Inheritance Arrow — Solid arrow pointing upward from subclass to superclass, showing that DigitalProduct and PhysicalProduct are kinds of Product.
• Association Line — Solid line connecting two classes to show they reference each other, such as Customer to Order.
• Multiplicity Notation — Numbers or ranges at each end of an association line (1, 0..*, 1..*) indicating how many instances can be linked.
• Composition Diamond — Filled diamond at the container end of a line showing strong ownership, such as Order containing LineItems.
• Aggregation Diamond — Hollow diamond showing weaker "has-a" relationship, for example a Warehouse containing inventory of Products.

When to use it

Use this template when designing the domain model for a new e-commerce system, onboarding team members to an existing shop's architecture, or preparing for backend development. It is ideal when you need to clarify how entities like products, orders, customers, and payments fit together before implementing a database schema or service layer. This diagram works well in design reviews and technical documentation.

Common mistakes

• Mixing too many different relationship types on one diagram, making it unreadable; focus on the core domain entities and their primary associations.
• Leaving multiplicities unmarked or vague, which leads to ambiguity about whether a Customer can have zero Orders or must have at least one.
• Adding implementation details like database IDs, getters and setters, or framework-specific annotations instead of keeping the diagram focused on business domain concepts.

Adapting it to your system

Start by listing your shop's key entities: if you sell subscriptions, add a Subscription class; if you handle reviews, add Review and Rating classes. Identify which classes own which: does an Order own its LineItems? Does a Customer own their Addresses? Draw inheritance where one type is clearly a specialization of another (VirtualCurrency as a type of Payment method). Add only the attributes and methods essential to understanding the domain; leave implementation details out. Adjust multiplicities to match your business rules: can an Order have zero items before checkout, or must it have at least one?