We don’t do it for every type, instead on a case by case basis. IDs are usually the obvious ones since we might have a Product class with fields like ProductId, BrandId, List[TagId], SellerId, etc... and it’d be nice to not mess that up.

Another example is if you have some pricing info you could group it in a case class like:

  case class PriceInfo(price: BigDecimal, discount: BigDecimal, currency: Currency)

And then put that into your product class:

  case class Product(id: ProductId, price: PriceInfo, ...)

The nice thing about this is that all these related fields can be dealt with in context, i.e. if a function accepts a PriceInfo then it now has access to the price itself and the currency. Not to mention that a price without currency in an e-commerce app can be quite ambiguous.