Imagine if you had a 100 interfaces for a resource (extreme example), in your example you would have to repeate same module/resource for each. The way it is now, you just put them in the resource block; or define them in the resource.

But I think I understand what you mean: it’s more intuitive to define it as an option. But in the case of defining an interface in a resource, what then? You wouldn’t mention the module? It would be less consistent.

Ya it’s funny—I think it does have to do with being new to Elixir because I see what OP means now that they’ve pointed it out but this never once occurred to me before!

@anibal maybe thinking of it as with_resource do would help but as mentioned, it’s really just about getting a clean way to define things. Macro-heavy DSLs can take some getting used to. It’s probably easier to not think of resources and resource as function calls but as a simplified language for creating data structures that are then fed into “real” functions. Incidentally, this is exactly what is happening behind the scenes!

For example, would the following be as surprising? (Note, this is a completely invented simplified example):

defmodule MyApp.Tweets do
  @behaviour Ash.Domain

  @impl true
  def domain do
    %{
      resources: [
        %{
          module: MyApp.Tweets.Tweet,
          define: [
            :tweet, action: :create, args: [:text]
          ]
        },
        %{
          module: MyApp.Tweets.Comment,
          define: [
            :comment, action: :create, args: [:tweet_id, :text]
          ]
        }
      ]
    }
  end
end

Ash could have been done in a manner like that, but the DSL is much nicer.

By defining the interface on the domain, you get something more akin to a “service”. i.e

MyApp.Accounts.register_user!(...)

vs

MyApp.Accounts.User.register_user!()

Defining them on the domain for the most part decouples the caller from the resource in charge of registering said user.