Indeed, using a new function, combined with declaring the struct’s type as @opaque (as hint that people should not construct it directly and in many cases not pattern match on it directly either) is the convention that is used for this. As for the return value in case of an error, there is no convention for this, (I have seen all of %MyStruct{} | nil, %MyStruct{} | {:error, reason} and {:ok, %MyStruct{}} | {:error, reason}; I like the third the most myself, but it depends on the situation).

As for the example with the Ecto changeset: I am not sure this is the proper way. It feels like you are partially re-inventing the logic that changesets themselves provide, but I am not immediately sure how to improve on it.

It feels more natural to me to have MyStruct.new() return a version of the struct with sensible default values (without any filled in ‘attrs’) and explicitly fill in the changeset with attrs at the place where you use it, i.e:

defmodule MyStructContext do
  def create_mystruct(attrs) do
    MyStruct.new
    |> creation_changeset(attrs)
    |> Repo.insert()
  end

  def creation_changeset(mystruct = %MyStruct, attrs) do
    mystruct
    |> MyStruct.common_changeset(attrs) # Ensures that invariants of MyStruct are never invalidated.
    |> Changeset.cast(attrs, [:someting, :only_applicable_on_creation])
    |> Changeset.validate_required([:something, :only_applicable_on_creation])
  end
end

I use validate_change for the embedded maps, which takes function as validator. This way you can compose validations pretty much for any imaginable structure.