Modeling domain with types in Elixir

[tomekowal]

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: "example@gmail.com"

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

  @spec run() :: :ok
  def run() do
    send_message(an_email())
    :ok
  end

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?

[peerreynders]

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

[hlalvesbr]

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#.

[tomekowal]

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 https://github.com/expede/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 https://github.com/wende/elchemy https://github.com/alpaca-lang/alpaca

[stefanluptak]

Gleam, a statically typed language for the Erlang VM

Gleam is a statically typed language for the Erlang VM that I have been slowly building over the last year or so. I’ve had a few people ask me about it so I’m making this thread as a place to talk about it. The type system features full type inference without annotations, generics, flexible and ad-hoc records using row types, first class modules, ADT style enums, and no null/nil/undefined or subtyping. Users of Elm, OCaml, ReasonML etc will probably find it quite familiar. Gleam compiles to Er…

Elchemy

So someone made another elm-like language to compile to the EVM called Elmchemy. It is not really much like Elm in style, only in syntax, so it is just another ml-style language, I’ve not looked closely to it yet, thoughts?

[zkessin]

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

[al2o3cr]

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} ->
    IO.puts(msg)
end

and with blocks can work like do-notation:

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

[imetallica]

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: "foo@bar.com"}

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

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

[Moxide]

Hello, you are not alone to “resonate” with the ideas presented in this great book
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: [])
    end
  end

  defmodule OrderLine do
    use TypedStruct

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

  defmodule ShippingAddress do
    use TypedStruct

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

  defmodule Order do
    use TypedStruct

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

  defmodule ValidatedOrder do
    use TypedStruct

    typedstruct enforce: true do
      field(:order, Order.t())
      field(:validation_date, DateTime.t())
    end
  end
end

defmodule TypeDemo do
  alias OrderTakingTypes.{OrderLines, OrderLine, ShippingAddress, Order, ValidatedOrder}

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

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

  @spec validate_order(Order.t()) :: ValidatedOrder.t() | ErrorResponse.t()
  def validate_order(%Order{order_lines: order_lines} = order) when length(order_lines) > 0 do
    %ValidatedOrder{
      order: order,
      validation_date: DateTime.utc_now()
    }
  end
  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")
end

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.

[tomekowal]

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!

[woohaaha]

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

[tomekowal]

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)
  end

  @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
    :ok
  end
end

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

Combined with other approaches from this talk: https://www.youtube.com/watch?v=XGeK9q6yjsg
it gives me a pretty nice domain-driven design

[woohaaha]

Thank you 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?

[woohaaha]

That was a great talk. Thanks for sharing Here’s a link to the explanation on @opaque incase anyone else is interested (https://youtu.be/XGeK9q6yjsg?t=588). Are you aware of any other talks like this (elixir specific)? I really enjoyed it!!!

[tomekowal]

@woohaaha

May I ask, are there any patterns you apply to Phoenix specifically?

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

Any downsides to using the same table for multiple contexts?

Understood. I usually have a struct because I have grabbed it to authorize. They are generally pretty thin, I think. In a lot of admin areas they are authorized at router level, so it is a simple case statement. Other areas have per action authorization which adds a with. Anything more intensive typically takes place in whatever context function is being called. Some of these functions within the context end up as big multis. In a few cases, a user is passed to the context function for autho…

[IvanR]

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)