Primitive Obsession is a result of poor practices. Primitive Obsession is a byproduct the impedance mismatch between OOD and ERD. Primitive Obsession is a code smell indicating procedural design - encouraged by some heavyweight framework.

Okay. But what does that look like? And, more importantly, how do I code my way out of it?

    PersonTypedDataSet GetPerson(Int64 personIdentifier);

This is your basic primitive obsession in action: use of primitive types as keys to a map (ERD, HashMap). This causes a flacid integration point. The parameter is an integral type - it has primitive rules regarding its domain and range. What means -1? Where do I get this magic number from? How do I remember what the number indicates? How do I get more information about this person number?

Can you see where this goes? There is very little object-oriented when it comes to primitive types. Yet frameworks such as COM, Corba, and even .NET promote coarse-grained modeling. Guidelines such as CLS-compliance, COM/IDL-compliance - when they insinuate into your library's internals - they encourage primitive obsession.

But...you can always code your way out of primitive obsession. And most languages give you an escape exit: operators. Let's take a look at a revised method signature - and then at the implementation that makes this work.

    PersonTypedDataSet GetPerson(PersonIdentifier personIdentifier);

Here we have a non-primitive argument - an instance of something in your class hierarchy. It carries its own behavior - which is really what proper design is about. You can now apply all sorts of design patterns to this non-primitive type. Need to change from Int64 to Guid as an underlying key...no problem. Need to validate range? No problem. And when it comes to unit-testing, the memento of SystemIdentifier is much more useful than Int64.

So what would SystemIdentifier look like in C#? Well, here is a basic case.