Domain specific types in a play framework project.

We can all agree that it’s useful to be able to express a number. Or a character. It could be argued that most code is built upon some set of primitives. And naturally simple types work well in a limited number of use cases: algorithms, tutorials, small/focused applications, etc.

The moment the domain outgrows the natural usage of a given primitive it becomes troublesome to keep in mind what the meaning behind a particular Int is. We all know this, it’s been the driving force behind OOP since day one.

Recently I’ve been working on an application based on play framework 2.4.x and slick 3.0. Unsurprisingly, as the app grew the need to track and control domain-specific data became more and more pressing.

Type aliases

It’s useful to be able to quickly start with something simple. Scala has type aliasing which provides a simplistic way of expressing intent.

Quick & easy but has some drawbacks:

The above code compiles fine but Mike might not be all that happy about it. The solution itself isn’t that bad: gives no type safety and serves only as a hint but it’s very cheap and can easily be employed as a ‘stub’ for a better solution. It’s important to stress that this approach doesn’t scale well: domain specific aliases x amount of developers x features implemented equals a misassignment bound to happen.

Unboxed Tagged Types

After reading this post I’ve decided to try if this approach could work with playand slick. The gist of this approach is that it’s possible to attach ‘meta information’ to a primitive type and the typer will enforce it.

Implementation (scalaz):

In practice it looks like this:

Mike can be at ease:


Having the basics covered I got to the interesting parts.

Helpful ‘Int’ extension:

Removes .asInstanceOf[A] invocations and converts primitives into domain types:

Slick mapper

Usage in table definition:

Play json formatting:

Play routes

This is where the trouble starts. To be able to use custom types in routes a path binding needs to be provided:

routes file:

And the error:

It turns out that:

is what play framework generates in Routes.scala.

The ramifications are quite annoying – instead of having type checking in routes file it’s necessary to handle boxing manually:


In tests:

It’s worth keeping in mind that unboxes tagged types and play jsondon’t align perfectly.

The proposed solution covers some of the aspects that would make it a valid solution for handling domain specific types. It falls short in a very important spot: ease of testing. The test code base should be (in my opinion) easy to maintain and refactor and loosing type safety in this area is a deal breaker.

At this point I was out of ideas on how to push this solution further so I decided to give a completely different approach a try.

Case classes

Case classes come with a set of limitations, but when the problem calls for type-safety, readability and ease of integration with common libraries (in this case play and slick), they quickly become valuable tools.

Value class with slick’s mapping

Json serialization

Int implicit extension

Play path binding

This way routes can utilize the type system:

and in tests:

A lot of the code base in a DB centric application will call for values: names, identifiers, nicks, etc. Not all of these need to be processed and if not – the above approach makes building applications easier and less error prone.


The previous paragraph shows how to integrate case classes with the stack but it introduces boilerplate. It’s not a lot but it seems wasteful and might be error prone. Maybe we can use some macro magic to make it go away?

Here’s my take on the problem, heavily inspired by this article.


annotation expansion

def macros

Providing def macros and utilizing them in the annotation macro made the json format visible for other already defined macros (e.g. Json.format). This way if another class uses one of the annotated case classes and defines an implicit Json.format the compiler won’t complain.

build.sbt macros section

One way to make the macro compilation order happy in a play application:


This solution uses macro paradise so it’s quite volatile (read experimentalsubject to change etc.) but it makes adding new simple domain specific types very straightforward: path bindingsjson serialization and slick integration just work ™ for all primitive types.

One thing that was omitted from the macro is primitive type extension.


It would be so useful to be able to reason about a primitive and have the compiler police it’s domain constraints. Disappointing but understandable – library authors have a lot of interop requirements to appease and a niche feature that seems to be a tad outside of how scala programming should look like isn’t a priority.

Case classes may not be the perfect solution but the approach is popular enough for library authors to provide out-of-the-box helpers that just work (e.g. slick’s MappedTo). And if not: it’s always possible (and quite easy) to figure out a macro or two that will meddle with the case class itself or its companion object and deal with boilerplate around the required implicits.


Do you like this post? Want to stay updated? Follow us on Twitter or subscribe to our Feed.

See also


Dominik Zajkowski

Latest Blogposts

15.06.2021 / By Tomasz Bogus

Why do Bitcoins have value?

What makes us pay $50,000 for one unit of cryptocurrency? Yet another day, yet another discussion about current cryptocurrencies’ prices in media and yet another headshake: “how is it possible that people choose to pay that much for something that is entirely digital and so volatile”? It is obvious that despite all the skepticism, cryptocurrencies […]

07.06.2021 / By Daria Karasek

5 Reasons Why Rust Is The Future

In the Stack overflow 2020 survey, Rust was picked as #1 most loved programming language, thanks to 86% of developers who said they would continue using it. For the language creators, this is nothing new – Rust has been winning the survey ever since 2016. On Tiobe Index, Rust is rising in popularity as well […]

01.06.2021 / By Tomasz Bogus

How does Bitcoin work?

A beginner’s guide to bitcoin cryptocurrency If you’ve been asking yourself a few times now: “how does Bitcoin work?” you’re in the right place. Bitcoin has always been present in the media – both traditional and social ones – but recent significant increases in its price, as well as the much-discussed public debut of Coinbase […]

Need a successful project?

Estimate project