Flexible, Correct Domain Models Using Type Families
At TripShot, we love Haskell. We especially love its powerful type system that allows you to model things exactly the way you intend. In this article, we’ll explore a common problem when modeling domain entities, look into some potential solutions and finally present the solution which we have implemented at TripShot.
Identifying the problem
At TripShot, we work with vehicles a lot, so let’s take a model of a Vehicle as an example.
1-- Other types omitted for brevity
2
3dataVehicle=Vehicle
4 { vehicleId ::VehicleId
5 , name ::VehicleName-- E.g. John's Van
6 , licensePlate ::LicensePlate
7 , make ::VehicleMake
8 , model ::VehicleModel
9 , vin ::VIN
10 , year ::Year
11 , weight ::Lbs
12 }Here we have a Vehicle with a bunch of vehicle-related fields. Nothing unlike most domain entities out there.
Now imagine someone made a typo in the vehicle name and we need to update it. We can’t do that now, so let’s write a function that updates a Vehicle. While we’re at it, we’ll also handle updates for more than the name field - mistakes happen, and we need to be able to correct them.
1dataVehicleUpdate=VehicleUpdate
2 { name ::VehicleName,
3 licensePlate ::LicensePlate,
4 make ::VehicleMake,
5 model ::VehicleModel,
6 vin ::VIN,
7 year ::Year
8 }
9
10updateVehicle ::VehicleUpdate->Vehicle->IOVehicle
11updateVehicle VehicleUpdate {..} vehicle =do
12 weight <- getWeightFromExternalService make model year
13
14return$
15 vehicle
16 { name = name,
17 licensePlate = licensePlate,
18 make = make,
19 model = model,
20 vin = vin,
21 year = year,
22 weight = weight
23 }Simple enough. You’ll notice two things:
- We don’t want to update the vehicleId field because that’s a unique identifier that we wish to preserve
- We don’t accept a weight field. Rather, we use the make, model and year to query an external service that will give us the weight.
While this works fine, we then need to duplicate every field besides the ones we want to be able to update in both VehicleUpdate and Vehicle. This can quickly get tedious when you introduce more operations such as creating a Vehicle.
1dataVehicleCreate=VehicleCreate
2 { name ::VehicleName,
3 licensePlate ::LicensePlate,
4 make ::VehicleMake,
5 model ::VehicleModel,
6 vin ::VIN,
7 year ::Year
8 }
9
10dataVehicleUpdate=VehicleUpdate
11 { name ::VehicleName,
12 licensePlate ::LicensePlate,
13 make ::VehicleMake,
14 model ::VehicleModel,
15 vin ::VIN,
16 year ::Year
17 }
18
19dataVehicle=Vehicle
20 { vehicleId ::VehicleId,
21 name ::VehicleName,
22 licensePlate ::LicensePlate,
23 make ::VehicleMake,
24 model ::VehicleModel,
25 vin ::VIN,
26 year ::Year,
27 weight ::Lbs
28 }In the real world, you’re likely to have a lot more fields. This can result in thousands of lines of duplication across domain models. Fortunately, Haskell offers a few mechanisms that can help us drastically reduce that.
Approach 1: Use GADTs
One way to remedy this situation is to use the GADTs language extension. It would look something like this:
1data VehicleData = VehicleData
2 { name :: VehicleName
3 , licensePlate :: LicensePlate
4 , make :: VehicleMake
5 , model :: VehicleModel
6 , vin :: VIN
7 , year :: Year
8 , weight :: Lbs
9 }
10
11data Form = Create | Update | Model
12
13data Vehicle (f :: Form) where
14 CreateVehicle :: VehicleData -> Vehicle 'Create
15 UpdateVehicle :: VehicleData -> Vehicle 'Update
16 Vehicle :: VehicleId -> VehicleData -> Lbs -> Vehicle 'Model
17
18updateVehicle :: Vehicle 'Update -> Vehicle 'Model -> IO (Vehicle 'Model)
19updateVehicle = ...We introduce a Form type that describes the shape of the model - for creating, for updating or for storing.
This has some benefits - we can use the Form type to state exactly the type of Vehicle we expect, but it isn’t very convenient to use due to the following reasons:
- We lost the built-in record fields and if we need those, we’ll need to write our own such as:
1vehicleId ::Vehicle'Model->VehicleId
2vehicleId (Vehicleid _ _ _ _) =id2. We lost the ability to derive Generic. If you’re a user of generic-lens or otherwise like deriving instances such as FromJSON that may be a significant hindrance.
Again, luckily for us, Haskell’s type system can help us overcome those challenges as well!
Approach 2: Use TypeFamilies
Using the same Form type we introduced in the GADTs example, we can define type families that determine what the type of a field should be during compile time. You can think of those type families as type-level functions.
1dataForm=Create|Update|Model
2
3-- This is nothing but a simple function using
4-- pattern matching, only it is at the type level
5typefamilyId (f ::Form) where
6-- We use the Unit type to signal "empty"
7Id'Create= ()
8Id'Update= ()
9Id'Model=VehicleId
10
11typefamilyWeight (f ::Form) where
12Weight'Create= ()
13Weight'Update= ()
14Weight'Model=Lbs
15
16dataVehicle (f ::Form) =Vehicle
17 { id ::Id f,
18 name ::VehicleName,
19 licensePlate ::LicensePlate,
20 make ::VehicleMake,
21 model ::VehicleModel,
22 vin ::VIN,
23 year ::Year,
24 weight ::Weight f
25 }
26
27updateVehicle ::Vehicle'Update->Vehicle'Model->IO (Vehicle'Model)
28updateVehicle =...
29
30createVehicle ::Vehicle'Create->IO (Vehicle'Model)
31createVehicle =...This is significantly less verbose than the GADTs example and with almost no drawbacks. We can easily derive Generic and use it for lenses or deriving various instances.
Deriving is a tiny bit more verbose than if we didn’t have the f parameter:
1data Vehicle (f :: Form) = Vehicle
2 { ...
3 }
4 deriving (Generic)
5
6deriving instance (ToJSON (Id f), ToJSON (Weight f)) => ToJSON (Vehicle f)
7deriving instance (FromJSON (Id f), FromJSON (Weight f)) => FromJSON (Vehicle f)
8Or we can use generic-lens with OverloadedLabels and get proper type inference:
9*> :t vehicle
10vehicle :: Vehicle 'Model
11
12*> :t vehicleCreate
13vehicleCreate :: Vehicle 'Create
14
15*> :t (vehicleCreate ^. #id)
16(vehicleCreate ^. #id) :: ()
17
18*> :t (vehicle ^. #id)
19(vehicle ^. #id) :: TextConclusion
At TripShot, we’ve found TypeFamilies to be an incredibly effective tool, enabling us to design more precise, flexible and maintainable systems. If you haven’t yet, we strongly encourage you to explore this approach. This use of TypeFamilies is also a great showcase of the power and flexibility of Haskell’s type system. We hope this inspires you to dive even deeper and discover more ways to build robust, well-designed systems.