UML class · Diagram Design

Payments domain · class diagram

PaymentMethod is the contract two payment methods realize. Order composes its line items and references a customer. PaymentService only depends on the interface, never the concrete methods.

Payments domain · UML class diagram Class diagram showing Card and BankTransfer realizing a PaymentMethod interface, PaymentService depending on PaymentMethod, and Order composed of OrderLine while associated with Customer. USES 1 1..* 0..* 1 «interface» PaymentMethod + authorize(amount: Money): AuthResult + capture(ref: String): void Card - number: String - expiry: Date - cvv: String BankTransfer - iban: String - accountHolder: String PaymentService + charge(order: Order): Receipt Order - id: String - placedAt: Date - total: Money OrderLine - sku: String - qty: Int - price: Money Customer - id: String - name: String - email: String LEGEND · RELATIONSHIPS Inheritance Realization Composition · owns Aggregation · has Association Dependency · uses

THE HEADLINE

PaymentMethod is the contract

Card and BankTransfer both realize the interface — the dashed line with the hollow triangle. PaymentService only ever talks to the interface, never to a concrete method.

Composition means it dies with the whole

  • OrderLine has no life outside an Order
  • Filled diamond sits at Order, the owner
  • Order also just references Customer — no shared lifecycle there

What's deliberately left out

No getters or setters, no full attribute lists. Every member shown earns its place in the argument this diagram is making.

Payments domain · UML class diagram example · diagram design