Relationships

An association is a structural, long-lived relationship: one object holds a reference to another, or to its identity, in a field, so the link outlives a single operation and has a direction and a multiplicity. A dependency is temporary use: the class needs the other type only during an operation, as a parameter, local variable, return type or static call, and keeps nothing afterwards. ReminderService storing a Mailer field is an association; issue(Order order, Clock clock) using the Clock only for that call is a dependency. In UML, association is a solid line and dependency a dashed arrow. Dependency is weaker, so prefer it when the collaborator is only needed occasionally.

Both are whole-part relationships, but they differ in who owns the lifecycle. In aggregation the parts exist independently of the whole and can be shared: players exist without a team and can move to another one, and tracks can appear in many playlists. In composition the whole owns its parts: it creates them, controls all changes to them and deletes them with itself, and each part belongs to exactly one whole at a time, like order lines in an order. In Java, composition usually means a private collection populated only by the whole's methods; in JPA it means cascading and orphan removal. UML marks aggregation with a hollow diamond and composition with a filled one.

For child entities, map the collection on the whole as @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true). Cascading means persisting, merging or removing the Order also applies to its OrderLine rows, and orphan removal deletes a line as soon as it is removed from the collection, so no row survives without its parent. For value objects without identity, use @Embedded for a single value such as a billing Address, stored in the owner's table, and @ElementCollection for a collection of values, stored in a table owned by the entity. Keep the collection private and expose methods such as addLine, so parts change only through the whole in code too.

A bidirectional association couples both classes to each other: each must know the other's type, and both sides must be kept consistent on every change. In JPA that means an @OneToMany with mappedBy plus an @ManyToOne, and code that sets line.order whenever a line is added; forget it and the in-memory model disagrees with what is persisted. Unidirectional associations halve that coupling, make ownership obvious and avoid accidental navigation into large object graphs, which also reduces lazy-loading surprises and serialisation cycles in JSON. Choose bidirectional only when navigation in both directions is a real, frequent need, and then hide the synchronisation inside helper methods on the owning side.

An aggregate is a consistency boundary, and referencing another aggregate by ID keeps that boundary visible in code. With an object reference, loading an Order can pull in the Customer and everything it references, causing lazy-loading traps, N+1 queries and huge graphs. It also tempts developers to change two aggregates in one transaction, which increases locking and optimistic-locking conflicts. Holding a CustomerId makes the dependency explicit: if the use case needs customer data, it loads the customer through its own repository. ID references also decouple persistence mappings, so each aggregate can be stored and evolved independently, and they still work when the other aggregate later moves into a separate service.

Dependency is the weakest relationship, because the class uses the collaborator only during one operation and keeps no reference afterwards. That means no long-lived state to keep consistent, nothing holding other objects reachable in memory, and a collaborator that can differ on every call, which suits things like a Clock, a RowWriter or a pricing context. Coupling is lowest when the parameter is an interface type and higher when the method calls new on a concrete class or a static method. Preferring the weakest relationship that still expresses the domain keeps classes easy to test and change. Promote a dependency to an association only when the collaborator is genuinely needed across many operations.

Relationship strength tells you what must stay together and where you can cut. Composition clusters, such as an order with its lines, share invariants and lifecycle, so they belong in one aggregate and therefore one module. Strong object associations between classes suggest they change together and also belong together. Associations by ID, and especially collaboration through events, are weak; they mark natural seams where a module boundary, and later perhaps a service boundary, can sit. When designing modules, I classify relationships first, keep strong ones inside a module, replace object references that cross modules with IDs or published views, and enforce the resulting dependency direction with ArchUnit or Spring Modulith.

Across services, the only shared reference is an identifier. The Order service stores a CustomerId, never a Customer object graph, and there are no foreign keys or joins across service databases, because each service owns its data. When a service needs data owned by another, it either calls that service's API on demand, which adds runtime coupling, or keeps a local, read-only copy of just the fields it needs, updated from events such as CustomerRenamed. That copy is eventually consistent, so the design must tolerate staleness, and values such as a delivery address are often snapshotted at order time anyway. Composition and cascades stay strictly inside one service's aggregates.