Primitive Obsession in Spring Boot DDD — before and after replacing UUID/Integer/String with Value Objects (code + video)

Your Compiler Could Have Caught This Bug. It Didn't. This post accompanies episode 2 of my DDD series — building a real parcel locker system in Spring Boot from scratch. Source code on GitLab. We had a method like this in our codebase: public Parcel assignParcelDimensions( Integer weightKg, Integer heightCm, Integer widthCm, Integer depthCm) { this.weightKg = weightKg; this.heightCm = heightCm; this.widthCm = widthCm; this.depthCm = depthCm; return this; } Four Integer parameters in a row. Swap two — it compiles. Passes review. Ships. And somewhere in production, a package ends up in the wrong locker because weight and width got mixed up. The compiler had all the information it needed to stop this. We just didn't give it the right types. The Problem: Primitive Obsession Here's the full Parcel domain class before we touched it: public final class Parcel { private final UUID parcelId; // any UUID fits — even a lockerId private Integer weightKg; // mutable, non-final private Integer heigh