The feature is NOT finished (draft), but I would like to understand the expectations from the API perspective. Opening the conversation to the public!

Due to the multi-tenancy architecture, I like the idea of having a way to control the global configuration as well as routing.

When it comes to the routing, I am not sure if use :commanded OTP scope to configure things (it feels like an anti-pattern to me) or ask the user to pass the otp_app option and if that option is defined, then I try to read the config for the given Router module.

I am not sure, I opened to gather feedback about the direction of the feature.

The two changes we want to make are to modify the default aggregate lifespan behaviour defined by Commanded to not keep aggregate processes running indefinitely and to allow this default to be configured per Commanded Application.

We can do this by changing the Commanded.Aggregates.DefaultLifespan module to return an appropriate timeout value, such as a few hours, which would mean that by default aggregates are stopped after a period of inactivity. This is already implemented in the Aggregate process and handled automatically by the GenServer handle_* callback function timeout. Changing this default would apply to all users of Commanded who have not explicitely defined an aggregate lifespan via a router module.

Secondly, we want to make the default aggregate timeout configurable per Commanded Application. This configuration could be set either in the use macro, in configuration (such as config/config.exs), or at runtime via the init/1 callback function. Ideally we should support all three, which in practice means we need to support runtime configuration.

# Configured by `use` macro
defmodule MyApp.Application do
  use Commanded.Application,
    otp_app: :my_app,
    aggregate_default_lifespan: MyDefaultAggregateLifespan
end

# Configured by config file (config/config.exs)
config :my_app, MyApp.Application, aggregate_default_lifespan: MyDefaultAggregateLifespan

# Configured at runtime
defmodule MyApp.Application do
  use Commanded.Application, otp_app: :my_app

  def init(config) do
    config = Keyword.put(config, :aggregate_default_lifespan, MyDefaultAggregateLifespan)
    {:ok, config}
  end
end

The following,

use Commanded.Application,
  otp_app: :my_app,
  aggregate_default_lifespan: MyDefaultAggregateLifespan

That could be done using default_dispatch_opts.lifespan

use Commanded.Application,
  otp_app: :my_app,
  default_dispatch_opts: [lifespan: MyDefaultAggregateLifespan]

config :my_app, MyApp.Application, aggregate_default_lifespan: MyDefaultAggregateLifespan

This is done, fallback to config :commanded, AppName, aggregate_default_lifespan: MyDefaultAggregateLifespan as well

Runtime (init) should be handle by the same default_dispatch_opts as far as I can tell,

 def init(config) do
        config =
          Keyword.update(
            config,
            :default_dispatch_opts,
            [],
            &Keyword.put(&1, :lifespan, MyDefaultAggregateLifespan)
          )

        {:ok, config}
 end

No?!

I think that such init/1 is being called at compile time, as of today, I never in runtime thou.

Regardless, do we really need to add every possible combination or should we be pragmatic about it until somebody ask to add more things?