Explore how to fully leverage Scala's type system to encode domain constraints and avoid common anti-patterns caused by primitive or ambiguous modeling.
Type-system underuse: Keeping important domain rules out of the type model even when Scala can express them cheaply and clearly.
Not every invariant belongs in types, but many Scala systems go too far the other way. They rely on strings, primitive IDs, booleans, and informal conventions where a small amount of modeling would prevent confusion and shrink the bug surface immediately.
Even in a language with rich type tools, it is easy to write models like this:
1case class Payment(userId: String, amount: BigDecimal, currency: String, status: String)
This compiles, but it loses several important distinctions:
userId is not any stringcurrency likely comes from a controlled setstatus has a known lifecycleThe anti-pattern is not using primitives at all. It is using them where the program would be safer and easier to understand with small domain-specific wrappers or ADTs.
When several fields all use String or Int, accidental swapping becomes easier:
UserIdOrderIdInvoiceIdIf those concepts matter operationally or across boundaries, giving them distinct types can prevent subtle mistakes and make APIs more self-documenting.
A common missed opportunity is allowing obviously invalid combinations because the model is too flat. Scala’s type system can often help by using:
For example, a workflow with mutually exclusive states is usually better represented as variants than as one record full of optional fields and status strings.
Well-chosen types do more than prevent bugs. They tell readers how to use the API. A return type such as Either[DomainError, Receipt] communicates more than a Boolean, and a parameter type like VerifiedEmail says more than String.
The type system becomes a design language, not only a safety net.
There is a balance. Underusing the type system is a real anti-pattern, but so is forcing every invariant into advanced machinery. The sweet spot is usually:
This gets much of the benefit without turning every feature into a type-level puzzle.
The code compiles, but the real meaning stays implicit and easy to misuse.
Validity depends on comments or discipline rather than on the model.
Callers are forced to guess why something failed or what kind of success they received.
Use the type system to distinguish domain concepts that matter, make invalid states harder to construct, and expose clearer API intent. In Scala, the goal is not maximum type sophistication. It is minimum ambiguity.