Modeling domain with types in Elixir

I am reading “Domain modelling made functional” and many ideas resonate with me. The examples are in F♯ but some ideas are general and transferrable to all languages.

One idea is that we should write types like UnverifiedEmail and VerifiedEmail and then

  @type unvalidated_email() :: String.t()
  @type validated_email() :: String.t()

  @spec validate_email(unvalidated_email()) :: validated_email()
  def validate_email(u), do: u

  @spec an_email() :: unvalidated_email()
  def an_email(), do: ""

  @spec send_message(validated_email()) :: :ok
  def send_message(_e), do: :ok

  @spec run() :: :ok
  def run() do

In F♯ code like that would fail to compile because send_message tries to use unverified email. Dialyzer success typing passes so I can’t enforce it with Dialyzer.

Another approach would be to use an %UnverifiedEmail{} struct and %VerifiedEmail{} structs all over the code.

That would require creating a lot of small (one field) structs. My questions are: have anyone tried modelling the domain with multiple structs? How much using a lot of structs affected compilation time?


Probably too naive an approach for your purpose - but here it is.

1 Like

Erlang and Elixir are more on the dynamic typed languages field. If you want strong guarantees at compile time, you should try Haskell, OCaml or F#.

Thanks. I need OTP so I won’t move to other language. I am just researching tools that might improve design in the project. I’ll check out Witchcraft It is not really idiomatic so I wanted to check if I can “simulate” type safety with something simpler.
Do you know any statically typed languages for BEAM? I know about

1 Like

The problem is that both types are defined as String.t(), what you want to do is define the types in some way that they can not mix. such as {:validated_email, String.t()} and {:unvalidated_email, String.t()} then dialyzer (and your pattern matching) can validate things.

@type validated_email() :: {:validated_email, String.t()}
@type unvalidated_email() :: {:unvalidated_email, String.t()}
@spec validate_email(unvalidated_email()) :: validated_email()
def validate_email({:unvalidated_email, u}), do: {:validated_email, u}

In general, in terms of types, a String is a String. so using an atom in a tuple or other data structure allows dialyzer to catch this.

This video goes over this in more details


I believe the “standard Elixir” way would be using tuples like @zkessin mentioned above; I read the Elixir form:

{:ok, value}

as mostly-equivalent to the Elm/Haskell form:

Ok value

Code can pattern-match values out of a tuple in function heads / case blocks.

case some_value do
  {:ok, result} ->
    # use result
  {:error, msg} ->

and with blocks can work like do-notation:

with {:ok, result1} <- operation_1(),
     {:ok, result2} <- operation_2(result1) do
  # use result2
  {:error, :operation_1_failed} ->
    # etc

Honestly, you cannot validate that on compile time, but you can enforce that on runtime via pattern matching. I would suggest something like this, although I feel it’s a bit of overkill:

def an_email(), do: %UnvalidatedEmail{email: ""}

@spec validate(UnvalidatedEmail.t) :: Email.t
def validate(%UnvalidatedEmail{email: email} do
  # Your validations here...
  %Email{email: email, valid: true}

@spec send_message(Email.t) :: :ok | {:error, term}
def send_message(%Email{valid: true} = email), do: :ok
def send_message(_), do: {:error, :invalid_email} 
1 Like

Hello, you are not alone to “resonate” with the ideas presented in this great book :wink:
When I tried to reproduce in Elixir some on the examples given, I used the “all is struct” approach and the typed_struct library.
Then played with VSCode and dialyzer (using the dialyzer underspecs and overspecs options).

Here is the code (just a POC ! ;-)) :

defmodule OrderTakingTypes do
  defmodule OrderLines do
    use TypedStruct

    typedstruct do
      field(:lines, list(OrderLine.t()), default: [])

  defmodule OrderLine do
    use TypedStruct

    typedstruct do
      field(:product_code, String.t(), enforce: true)
      field(:quantity, number(), default: 0)
      field(:price, number(), default: 0)

  defmodule ShippingAddress do
    use TypedStruct

    typedstruct enforce: true do
      field(:town, String.t())
      field(:zip_code, String.t())

  defmodule Order do
    use TypedStruct

    typedstruct enforce: true do
      field(:shipping_address, ShippingAddress.t())
      field(:order_lines, list(OrderLine.t()))

  defmodule ValidatedOrder do
    use TypedStruct

    typedstruct enforce: true do
      field(:order, Order.t())
      field(:validation_date, DateTime.t())
defmodule TypeDemo do
  alias OrderTakingTypes.{OrderLines, OrderLine, ShippingAddress, Order, ValidatedOrder}

  def send() do
      lines: [
        %OrderLine{price: 10, product_code: "SKU-0001", quantity: 5}
    |> send_to(%ShippingAddress{zip_code: "69000", town: "Lyon"})

  @spec send_to(OrderLines.t(), ShippingAddress.t()) :: :ok
  def send_to(%OrderLines{lines: order_lines}, %ShippingAddress{} = address) do
      shipping_address: address,
      order_lines: order_lines
    |> validate_order()
    |> process_order()

  @spec validate_order(Order.t()) :: ValidatedOrder.t() | ErrorResponse.t()
  def validate_order(%Order{order_lines: order_lines} = order) when length(order_lines) > 0 do
      order: order,
      validation_date: DateTime.utc_now()
  def validate_order(%Order{order_lines: order_lines}) when length(order_lines) == 0,
    do: %ErrorResponse{code: 500, message: "OrderLines cannot be empty"}
  def validate_order(_), do: %ErrorResponse{code: 500, message: "Unknown error"}

  @spec process_order(ValidatedOrder.t() | ErrorResponse.t()) :: :ok
  def process_order(%ValidatedOrder{
        order: %Order{shipping_address: %ShippingAddress{town: town, zip_code: zip_code}}
      do: IO.puts("Processed shipping to #{zip_code}, #{town}")
  def process_order(%ErrorResponse{code: code, message: message}),
    do: IO.puts("Error occured with code '#{code}' and message '#{message}'")
  def process_order(_), do: IO.puts("Weird error")

Depending of the type of error you introduce (missing return type in @spec for instance) and on the Dialyzer options, it will be too verbose or too silent.


So, there is at least a couple of different methods.
Using tagged tuples, structs, macros with structs alone, macros generating structs and types like in typed_struct or algae.
Building on that there are a couple of libraries for handling flows with errors ok_jose, exceptional, witchcraft (which has also more functors, monands, monodis and so on).
I wish there was a standard way of doing this stuff either baked into the language or a library that people agree to use (like it was with Timex).

Thanks for your input!


It has been some time since you’ve asked this question. Have you settled on a pattern you enjoy using? If so, mind sharing a contrived elixir example? Thank you

Yes! I’ve learned that Dialyzer has @opaque directive.

If you mark a type as @opaque, you can use it inside the module it is defined. Outside the module, you can pass the opaque type around, but you can’t access its fields. This directive renders @imetallica solution great! E.g.

defmodule Email do
  defstcut :email
  @opaque t() :: %__MODULE__{email: string()}

  @spec validate(String.t()) :: t()
  def validate(string_email) do
    #... validations
    # if this is the only place you return that struct, dialyzer will make sure nobody else creates or modifies the struct
    %__MODULE__{email: string_email)

  @spec send(t()) :: :ok | :error
  def send(%__MODULE__{email: string_email}) do
    #access to the field is OK because you can use @opaque type fields in the same module

def OtherModule do
  def test() do
    valid_email = Email.validate("")
    %Email{email | email: "something_broken"} #dialyzer will complain because the type is opaque

Combined with other approaches from this talk:
it gives me a pretty nice domain-driven design :slight_smile:


Thank you :clap: I will watch the video. For the code I’ll have to refer to the docs. May I ask, are there any patterns you apply to Phoenix specifically? :bowing_man:

That was a great talk. Thanks for sharing :clap: :smile: :+1: Here’s a link to the explanation on @opaque incase anyone else is interested ( Are you aware of any other talks like this (elixir specific)? I really enjoyed it!!!


Not really. Phoenix tries to be a non-intrusive framework. When you pick JQuery, you no longer use plain old JS, when you pick Rails, you almost don’t use plain old Ruby. When you pick Phoenix, it gets out of your way. Elixir patterns apply in Phoenix.

There was a topic here on Elixir Forum that from a design question spiralled into a design discussion :slight_smile:

1 Like

Hey folks, I was inspired by Scott Wlaschin’s domain model examples from his book Domain Modeling Made Functional. That was for F#, and I made a library that allows us to express the same examples in Elixir.

Please, have a look at Domo User defined tags and type-safe structs for domain modelling (Domo library)