Campaign stores

A store is persistence only. Batches, status changes and events live in the actions, so a store just keeps campaigns and their recipients. The configured one (config: store, env CAMPAIGNS_STORE) is bound in the container as Contracts\CampaignStore — scoped, so each request or queued job gets its own — and its reads return copies — changing a returned object changes nothing until it is saved:

use RoundlyConsulting\Campaigns\Contracts\CampaignStore;

// The configured store, as the actions see it (bound scoped — one per request or queued job):
$store = app(CampaignStore::class);

$store->find('e184d08f-5081-4fbb-9604-7a2460c3fb3a');         // ?Campaign — a copy
$store->recipients('e184d08f-5081-4fbb-9604-7a2460c3fb3a');   // Collection<int, CampaignRecipient>
$store->countRecipients('e184d08f-5081-4fbb-9604-7a2460c3fb3a'); // RecipientCounts: total, processed, failed

The contract

insert() (refuse a taken uuid) and saveIfStatus() (write only while the stored status is the expected one) must each be one atomic step: they are what make duplicate uuids and racing starts safe.

Shipped stores

• Stores\InMemoryCampaignStore (default) — keeps campaigns in memory for the current request, console command or queued job. Ideal for tests and create-and-send flows; nothing survives it.
• Stores\DatabaseCampaignStore — keeps campaigns in the CampaignRecord and CampaignRecipientRecord models. See Database persistence.

Both run through one shared contract test suite, so they behave identically. To keep campaigns anywhere else, implement Contracts\CampaignStore and point the config at it — it’s resolved from the container, so constructor dependencies are injected:

// config/campaigns.php
'store' => \App\Campaigns\ApiCampaignStore::class, // implements Contracts\CampaignStore

Code that sends campaigns never talks to the store directly — it goes through the Campaigns facade, an injected CampaignManager or the actions (see DI and actions).