E-commerce domain model
Customer, address, order, line item, product, payment and a status enum — the nouns behind every checkout. The usual starting point for any transactional product.
7 classes · 6 relationships
UML Class Diagram Templates
Eight dense, fully-populated class diagrams. Open one and it's on the canvas right away. Then talk it down to your system: "drop Payment, rename Member to Subscriber, make Repository an interface."
Pick a template
Every diagram here is rendered from the same structured definition you get when you import it — nothing is a touched-up screenshot. The previews show classes and relationships only, so the shape stays readable at card size; click any one to see it in full, with every field and method. "Refine in chat" puts the diagram on the canvas and opens the conversation panel, so your first sentence can start changing it; "Use this template" drops it into the editor and leaves the rest to you.
User, role & permission (RBAC)
The access-control picture you redraw at every security review: users hold roles, roles grant permissions, sessions expire, and a policy interface keeps the evaluator swappable.
7 classes · 6 relationships
Library loan system
Book versus physical copy, loans, reservations and fines. The clearest way to show aggregation and composition side by side without inventing a toy domain.
7 classes · 8 relationships
Strategy pattern (payments)
One interface, three interchangeable implementations, plus a factory. The shape reviewers recognise before they read a word of the RFC.
7 classes · 6 relationships
Abstract base class & inheritance
Abstract methods, overrides, a two-level hierarchy and a Drawable interface. Use it to explain inheritance itself, or as the skeleton of any polymorphic design.
8 classes · 7 relationships
Layered service architecture
Controller depends on service, service is wired to interfaces, two adapters implement each one. The picture that makes a dependency-inversion argument land.
9 classes · 8 relationships
Blog / CMS content model
Posts, revisions, authors, categories, tags, comments and media — the many-to-many mesh every content schema must settle before the first migration.
7 classes · 7 relationships
Observer pattern (event stream)
A publisher notifying subscribers it knows nothing about. Handy for documenting event buses, hooks, and anything called "listener" in your codebase.
8 classes · 7 relationships
How to use these templates
1. Take the densest diagram, not the closest one
Counter-intuitive, but it works: pick the template with more classes than you need. Deleting a class you can see is a two-second decision; remembering a class you forgot to draw costs another review round.
2. Open it — the whole diagram is already drawn
The diagram is on the canvas the moment the page loads, with visibility markers, multiplicities, interfaces and all six arrow types already in place.
3. Talk it down to your system
Open the chat panel and correct it in sentences: "drop Payment, rename Member to Subscriber, make Repository an interface, add an ownership arrow from Team to Project." The assistant edits the same structured diagram you are looking at, so each turn returns a redrawn version rather than a fresh guess.
4. Hand-edit and export
The split view puts the Mermaid source next to the preview for the last few touches. Then SVG for docs that get zoomed, PNG for slides and tickets, or the raw source committed next to the code it describes.
What is a class diagram?
A UML class diagram is a structural view of a system: the types it contains, the data each type holds, the operations it exposes, and the relationships that tie them together. It answers "what is this system made of" — not "what happens when a user clicks buy", which is what a sequence diagram is for.
Engineers reach for it in three places above all: onboarding docs, where one picture replaces an afternoon of reading models; design RFCs, where a proposed hierarchy has to be argued about before it is written; and refactor plans, where a before-and-after pair makes breaking changes impossible to hide.
Mermaid's classDiagram syntax covers the notation that actually gets used in engineering docs — visibility markers, stereotypes such as <<interface>> and <<abstract>>, generics, multiplicities and all six relationship arrows. It stops short of full UML: no swimlanes, no activity semantics. For most documents that is a feature, not a gap.
The three parts of a class
A class box has three compartments. Only the first is mandatory — a class with no attributes and no operations is perfectly legal, and useful when you are drawing relationships first and filling in detail later.
- Class name — the type itself, in the top compartment. Stereotypes such as <<interface>>, <<abstract>> or a team-specific <<aggregate root>> sit here too.
- Attributes — the data the class holds, written as visibility, then name and type. This is the compartment reviewers scan for missing fields.
- Operations — the methods, with parameters and return type. Keep to the ones that carry meaning; a diagram listing every getter stops being readable.
Visibility and classifiers
- +
- Public — callable from anywhere
- -
- Private — internal to the class
- #
- Protected — the class and its subclasses
- ~
- Package / internal visibility
- *
- Abstract member, written after the parentheses: area()*
- $
- Static member, written the same way: of()$
Generics use tildes rather than angle brackets — List~Order~ renders as List<Order>. Square-bracket array syntax is not part of the grammar, so prefer the tilde form.
Relationships in a class diagram
Six arrows carry almost all the meaning in a class diagram. Getting them right is the difference between a picture that documents your design and one that quietly misrepresents it — reviewers do read the diamonds.
Inheritance
<|--A solid line with a hollow triangle pointing at the parent. The child is a specialised kind of the parent and inherits its attributes and operations. Say "Dog extends Animal" in chat and you get this arrow.
Realization (implements)
<|..Dashed line, hollow triangle. The class implements a contract declared elsewhere — an interface or an abstract type. The one people forget Mermaid even has; say "implements the X interface" and it appears.
Composition
*--Solid line with a filled diamond on the owner. The part cannot outlive the whole: delete the Order and its LineItems go with it. Reach for it whenever the child has no identity of its own.
Aggregation
o--Solid line with a hollow diamond. A has-a relationship where the part survives independently — a Player still exists after the Team folds. Unsure which? Ask whether the child is ever queried on its own.
Association
-->A plain solid line, optionally with a direction, a label and multiplicities such as "1" and "*". The default when two classes simply know about each other. Most of a domain model is made of these.
Dependency
..>Dashed line with an open arrowhead. The weakest link: one class uses another as a parameter, a return type or a local — but holds no reference to it. Good for showing what a controller calls without implying ownership.
Nothing close enough?
Describe your system in a sentence or two and let the generator draw the first version — then refine it exactly the same way.
Open the generatorFrequently asked questions
Do I need an account to use a template?
No. Opening a template and editing the Mermaid source by hand needs no signup at all — it happens entirely in your browser. Refining the diagram by conversation is where signing in comes in.
How do I change a template after importing it?
Two ways, suited to different edits. Chat is for structural changes described in words — "merge these two classes", "make Repository an interface", "drop everything below Order" — and returns a redrawn diagram each turn. The split-view editor is for surgical ones: fix a typo in a method name, retitle a relationship, reorder members. Most people import, talk the shape into place, then polish in the editor.
Does the assistant actually understand the imported diagram?
Yes, because the template is structured data rather than a picture or a blob of text. The imported classes and relationships become the conversation's working state, so "delete Payment" removes that exact class and everything attached to it — the assistant is not re-guessing your diagram from a description of it.
What is the difference between a class diagram and an ER diagram?
A class diagram describes code — types with behaviour, including methods, inheritance and interfaces. An ER diagram describes stored data — tables, columns, keys and cardinality, with no behaviour at all. If the thing you are drawing has methods, it is a class diagram; if it maps to a schema migration, it is an ERD.
Should I use composition or aggregation?
Ask whether the part can exist on its own. If deleting the whole must delete the part — an Order and its LineItems — that is composition, drawn with a filled diamond. If the part survives independently, like a Player after the Team disbands, that is aggregation with a hollow diamond. When genuinely unsure, a plain association is more honest than a wrong diamond.
How do I show an interface in a Mermaid class diagram?
Put the <<interface>> stereotype inside the class body, then connect implementations with the dashed realization arrow <|.. — as in PaymentStrategy <|.. StripeStrategy. The same mechanism gives you <<abstract>>, <<enumeration>> and any stereotype your team uses. Four of the templates here show it in place.
What export formats are supported?
SVG, PNG, and the raw Mermaid source. SVG stays sharp at any zoom, which matters for large hierarchies; PNG pastes cleanly into slide decks and issue trackers; and the Mermaid source can be committed alongside your code so the diagram is reviewed like everything else.
How many classes can one diagram hold before it stops being useful?
Readability, not the tool, is the limit. Past roughly fifteen classes people stop tracing lines. Split by bounded context or by layer and link the diagrams from a parent document — several focused pictures beat one wall chart. The templates here sit deliberately just under that line.
Related
AI class diagram generatorStart from prose instead of a template: describe classes, get Mermaid.UML diagrams from textClass, sequence and state diagrams — the whole UML family in one place.ER diagram generatorFor the storage side: tables, keys and cardinality instead of methods.Diagram from codePaste a file or a schema and let the model infer the structure.