Class relationships matter because they describe ownership, lifetime, and dependency between business concepts.

Why it matters in real Java systems

In an e-commerce domain, an Order is composed of OrderLines. A Customer may be associated with Orders over time. A Shipment might aggregate packaged items but still reference external warehouse data. Those distinctions guide lifecycle, persistence, and invariants.

The design idea behind this topic

Association is the broadest relationship. A Customer and an Order are associated because the order belongs to the customer contextually, but the customer object and order object can exist independently in the system.

Aggregation is often subtle in code because Java references alone do not enforce lifecycle. It is mostly a modelling distinction that helps express “contains, but does not fully own.”

Composition is often the most useful for OOAD because it tells you where invariants belong. If an Order is composed of OrderLines, then the order should often control how those lines are created, validated, and changed.

Key ideas to hold onto

Java example in the Order Management domain

package org.javaomnibus.ecommerce.foundations;

import java.util.ArrayList;
import java.util.List;

public final class Order {
    private final String orderId;
    private final Customer customer; // association
    private final List lines = new ArrayList<>(); // composition

    public Order(String orderId, Customer customer) {
        this.orderId = orderId;
        this.customer = customer;
    }

    public void addLine(String sku, int quantity) {
        lines.add(new OrderLine(sku, quantity));
    }

    public List lines() {
        return List.copyOf(lines);
    }
}

record Customer(String customerId, String name) {}
record OrderLine(String sku, int quantity) {}

Step by step

1. Customer is associated with Order, but the order does not own the lifecycle of the customer record.
2. OrderLine is treated as part of the Order’s internal composition because the order creates and contains it.
3. The addLine method makes ownership clearer than exposing raw mutable line lists.
4. These choices influence later modelling decisions such as validation and persistence boundaries.

Where this shows up in practice

• Deciding whether nested objects should be edited directly or only through the aggregate root
• Determining where lifecycle and validation rules belong in domain models
• Clarifying UML diagrams so they reflect actual code and domain meaning

When not to over-apply it

These relationships can be over-formalized. In Java, the code alone will not enforce all lifecycle semantics, so the model and team conventions must support the intent.

Frequent mistakes to watch for

• Using composition language in diagrams without reflecting it in the code model
• Treating every reference field as a strong ownership relationship
• Ignoring lifecycle implications when choosing where nested objects are created or modified
• Using UML terms without connecting them to business meaning

Related concepts