Domain Model Class Diagram
The code
classDiagram
class Customer {
+String email
+String name
}
class Order {
+Date placedAt
+String status
+total() Money
}
class LineItem {
+int quantity
+unitPrice() Money
}
class Product {
+String title
+Money price
}
Order --> Customer
Order --> LineItem
LineItem --> Product
How this template works
A domain model diagram is the fastest way to align engineers and product people on the nouns of a system. This template models a small order domain: a Customer places an Order, the Order is composed of LineItems, and each LineItem points at the Product it sells. Two behavior methods, total() on the order and unitPrice() on the line item, show where the money logic lives without dragging in implementation detail.
The syntax splits cleanly in half. The four class blocks each declare a name and a member list inside curly braces. Attribute lines put visibility first, then type, then name — +String email is a public string attribute. Method lines add parentheses and an optional return type after them, so +total() Money is a public method returning Money. The three relationship lines at the bottom are directed associations: Order --> Customer means an order knows which customer placed it, and the arrowhead marks the reading direction. Nothing in this file needs a parent-child relationship, so there are no inheritance arrows to worry about.
The gotcha is that Mermaid treats every type word as free text. Money is not a built-in type; it renders exactly as written, which is a feature when you are modeling a value object and a bug when someone typos Monry into the file. Keep a shared vocabulary for these type names, and remember that association direction matters to readers even though the renderer will happily draw either way.
To extend the model, start from the nouns your own domain uses and keep one class block per noun. When the same field starts appearing on several classes, promote it into a class of its own and point the references at it; when two classes keep duplicating the same lookup logic, pull that into a repository. Every change is one block plus one association line, and the diagram stays legible as long as you resist drawing arrows between every pair of classes.
Related templates that build on this one: the strategy pattern class diagram for behavior-focused design, the API SDK class diagram for client library layering, and the inheritance hierarchy class diagram for subtype trees. The class diagram guide explains every arrow type.
Variations to try
- Add a Money class with currency and amount attributes and point the price fields at it.
- Add a Repository class with find and save methods and associate it with Order.
- Add a Discount class and associate it with Order to model promotions.
