Skip to main content

Data Clumps

Data Clumps are field or parameter groups that always travel together, revealing a missing abstraction. Extract them into a value object or parameter object that owns the group's data, behavior, and invariants.

Data Clumps are groups of data items that keep appearing together — the same three or four fields in many classes, or the same cluster of parameters across many method signatures. startDate and endDate; x, y, z; street, city, zip, country. When the same set travels together, it is usually a hidden concept missing its own type.

Why It Happens

When a concept first appears, its parts are added as loose fields or parameters. Reusing them elsewhere means copying the same set rather than referencing a shared type, because no type exists yet. The clump propagates by imitation, so by the time the pattern is obvious it is already widespread.

Why It Hurts

Because the clump is not an object, behavior that belongs to it (validating that endDate is after startDate, computing a distance from coordinates) has nowhere to live and is reimplemented wherever the clump appears. Validation is duplicated and inconsistent. A change to the concept — adding a field, changing a rule — must be applied at every site that carries the clump, a form of shotgun surgery. Method signatures stay long, and the missing abstraction keeps the design from expressing the domain.

Warning Signs

  • The same two-to-four fields declared together in multiple classes.
  • The same parameter group passed to many methods.
  • Validation or computation over the group copy-pasted in several places.
  • Removing one member of the group from a call breaks meaning.

Better Alternatives

Extract the clump into a value object or parameter objectDateRange, Coordinate, Address — that holds the fields and owns their behavior and invariants. Domain-driven design recognizes these as the small building blocks of an expressive model. A good test: if removing one field from the group leaves the rest meaningless, they belong in one type.

How to Refactor Out of It

Name the concept the clump represents and create a class for it, moving related validation and computation onto it. Replace one clump occurrence at a time, starting where behavior is duplicated, and let the compiler help find the rest. Update method signatures to take the new object instead of the loose members. As behavior migrates onto the type, duplicated checks across the codebase collapse into one definition, and signatures shorten.