Once you have successfully identified the core entities within your system, the next critical step in Low-Level Design (LLD) is determining how these entities connect, communicate, and depend on one another.

Key ideas:

  • Entities do not exist in isolation; they must collaborate with other objects to satisfy business requirements.

  • Correctly defining relationships prevents messy coupling, reduces structural dependencies, and ensures clean memory management.

  • Relationships identified in your conceptual modeling phase map directly to how objects hold references, pointers, or collections of each other in code.

Real-world analogies:

  • A Driver operates a Car (Interaction/Collaboration).

  • A University contains multiple Departments (Loose Ownership).

  • A House is built out of Rooms (Strict Lifetime Ownership).

The Relationship Spectrum (High Level)

In object-oriented design, the connections between classes fall under a spectrum of dependency and ownership. While "Association" is the broad umbrella term for any structural linkage between two independent classes, it narrows down into more specialized forms based on how tightly bound their lifetimes are.

At a high level, we can classify these connections into three primary categories:

  • Association: "Class A interacts with Class B." Both objects have entirely independent lifecycles, and no clear ownership is implied.

  • Aggregation: "Class A has a Class B, but Class B can exist completely on its own." This represents a loose whole-part relationship where the container doesn't control the life of the child.

  • Composition: "Class A owns Class B; Class B cannot exist without Class A." This is a strict whole-part relationship with a shared, dependent lifetime.

Understanding Plain Association

An association is a general relationship between two classes that states: "Objects of these classes are aware of each other and can interact."

Key features:

  • It does not imply that one object dominates or owns the other.

  • It does not tightly bind their creation or destruction in memory.

  • It simply means there is a meaningful structural link allowing one object to invoke methods on another.

Simple One-to-One Association Example

Consider a Driver and a Ride In a ride-hailing system. They are separate concepts representing independent real-world items. A driver can exist without an active ride, and a ride request exists independently before a driver is even assigned. Deleting a Ride object from memory should never be destroyed; the corresponding Driver object.

Example design in C++:


Usage:


Here, Ride refers to a Driver via a pointer. Ride Does not manage the memory allocation or deallocation of the driver. If r1 is destroyed, d1 continues to exist. This is a plain association.

One-to-Many Association Example

Associations frequently present themselves in a one-to-many format, where one entity holds context for multiple instances of another over time. For example, one Customer can log multiple separate SupportTicket instances.

Example implementation:


Objects here remain fully independent. One customer is associated with many tickets, but deleting an individual support ticket does not erase the customer from the system.

When designing your entities, you must decide which directions the awareness flows:

  • Unidirectional: Only one class knows about the other. For example, a Ride stores a pointer to a Driver, but the Driver class does not keep an internal list of all its past Ride objects.

  • Bidirectional: Both classes store references to each other. For example, a User holds a reference to their Profile, and the Profile holds a reference back to its owning User.

For clean LLD, always default to unidirectional associations unless a bidirectional link is explicitly required by your use case. Keeping associations one-way significantly simplifies code maintenance, saves memory, and avoids circular dependency compilation issues.

Deepening the Relationship: Aggregation vs. Composition

To model complex structures correctly, you must know when an association upgrades to aggregation or composition based on structural ownership.

Aggregation (Weak Ownership)

Aggregation is a specialized form of association that models a "Has-A" or "Whole-Part" relationship where the child part can outlive the parent whole. The parent container aggregates the child, but it does not claim total lifecycle ownership.

  • Real-World Example: A Department has a list of Professors. If the department gets shut down or deleted, the professors do not cease to exist; they are independent entities who can simply transition to a different department.


Composition (Strong Ownership)

Composition is a strict structural relationship where the child component cannot exist outside the context of the parent container. The parent completely manages the creation, lifetime, and destruction of the child parts. If the parent dies, the children die with them.

  • Real-World Example: A House has a set of Rooms. A room cannot exist floating in space without a house structure around it. If you destroy the House object, the individual internal Room Objects must be destroyed simultaneously.


Representing Relationships in LLD Diagrams

When translating your real-world observations into UML standard structural diagrams, use the following notation conventions to indicate relationships clearly:

  • Plain Association: A simple solid line connecting Class A to Class B. You can add arrows to indicate navigability directions and numbers (multiplicity) like 1  * to indicate scale.

  • Aggregation: A solid line with an open, unfilled diamond attached directly to the parent container class.

  • Composition: A solid line with a solid, filled black diamond attached directly to the parent container class.

Summary

Correctly identifying structural links brings order to your domain objects:

  • Relationships define how independent entities share knowledge and coordinate work.

  • Plain association implies pure interaction without enforcing structural memory ownership.

  • Aggregation models lose part-whole collections, while composition tightly links object lifetimes together.