DI and actions

The facade is the recommended default, not the only way in. Three entry points run the same code: the Addresses facade (shortest), the manager RoundlyConsulting\Addresses\AddressManager — the facade root, an autowired container singleton — injected through the constructor (same API, explicit dependency, no static calls), and actions (single-purpose classes with execute(), for composing into your own actions, jobs and commands).

Inject the manager

use App\Models\User;
use RoundlyConsulting\Addresses\Actions\CreateAddressAction;
use RoundlyConsulting\Addresses\Address;
use RoundlyConsulting\Addresses\AddressManager;
use RoundlyConsulting\Addresses\DataTransferObjects\AddressData;

final class SaveBillingAddress
{
    public function __construct(private AddressManager $addresses) {}

    public function __invoke(User $user, AddressData $data): Address
    {
        return $this->addresses->for($user)->add($data);
    }
}

app(CreateAddressAction::class)->execute($user, $data);   // the raw action

Facade method → action

• Every owner-scoped call — from the facade, an address book, the builder or a HasAddresses shortcut — goes through the manager, so host overrides and Addresses::fake() see it.
• Addresses::fake() swaps the manager in the container too, so injected managers are faked as well. An action you call directly bypasses the fake and runs for real.
• The actions resolve from the container and take any Eloquent model as the owner — the HasAddresses trait is not required.
• PromoteAddressAction is internal — the primary invariant behind add, update and setPrimary. Promote an address with Addresses::for($owner)->setPrimary($address).