У notification-системі легко почати з простого listener: подія сталася, перевірити кілька умов і викликати send.
Проблема з’являється пізніше. Один listener перевіряє permission, інший user preferences, третій активність template, четвертий channels. Через кілька feature ті самі правила вже живуть у різних місцях.
Я віддаю перевагу окремому notification policy: один компонент вирішує, чи треба створювати notification, кому її доставляти і через які channels. Listener лише передає факт бізнес-події.
Listener, який знає забагато
public function handle(PostPublished $event): void{ $user = $event->post->author; if ($user === null) { return; } if (! $user->can('posts_create')) { return; } if (! $this->template->isActive()) { return; } Поки listener один, це здається нормальним. Коли ті самі перевірки з’являються у scheduled publication, account events і системних нагадуваннях, кожен listener починає мати власну версію policy.
Listener повинен залишатися тонким
Listener має знати, що сталося, і передати typed context. Він не повинен сам визначати recipient, preferences, template, channels і global delivery rules.
public function handle(PostPublished $event): void{ $decision = $this->policy->decide( NotificationContext::forPost( post: $event->post, trigger: NotificationTrigger::ScheduledPostPublished, ), ); $this->delivery->deliver($decision);}Policy має повертати структуроване рішення
final readonly class NotificationDecision{ public function __construct( public bool $shouldSend, public ?User $recipient, public ?NotificationTemplate $template, public string $locale, public array $channels, public ?string $eventKey, public ?string $skipReason, ) { }}Простого true або false замало. Delivery service потрібні recipient, template, locale, channels, event key та причина skip.
Що саме вирішує policy
Я б залишила в policy такий порядок:
- визначити recipient;
- перевірити business permission rules;
- знайти активний notification template;
- перевірити global automatic-delivery gate;
- отримати template channels;
- отримати channels з user preferences;
- побудувати фактичний channel set;
- сформувати event key для idempotency;
- повернути send або skip із reason code.
Channels - це перетин правил
$channels = array_values( array_intersect( $template->enabledChannels(), $preferences->allowedChannels(), ),); if ($channels === []) { return NotificationDecision::skip( reason: 'no_allowed_channels', );}Template може підтримувати database, broadcast і mail, але user preferences можуть заборонити mail. Фактичний набір channels має визначатися одним resolver, а не окремими if у listener.
Глобальний delivery gate має бути один
Якщо automatic notifications можна глобально вимкнути, цю перевірку не потрібно копіювати у кожен listener. Один gate дає однакову operational поведінку для всіх automatic notification flows.
Policy вирішує, delivery service виконує
Policy відповідає на запитання "що дозволено?". Delivery service відповідає на запитання "як це безпечно доставити?".
Delivery service може володіти idempotency ledger, database notification, broadcast, mail, retries і technical outcome. Він не повинен повторно визначати recipient або preferences.
$decision = $policy->decide($context); if (! $decision->shouldSend) { return DeliveryResult::skipped( $decision->skipReason, );} return $trackedDelivery->send( recipient: $decision->recipient, template: $decision->template, channels: $decision->channels, eventKey: $decision->eventKey,);Reason codes роблять skip зрозумілим
Якщо listener просто робить return, під час QA складно зрозуміти причину. Reason codes на кшталт missing_recipient, permission_denied, template_inactive, delivery_disabled або no_allowed_channels роблять рішення спостережуваним.
Не робіть один гігантський policy
Централізація не означає один клас на тисячу рядків. Спільні правила залишаються в reusable services: template resolver, channel resolver, preference resolver і delivery gate.
Trigger-specific policy містить лише бізнесову специфіку: хто recipient, яка eligibility і як формується event key.
Як виглядає повний flow
- domain event або scheduler знаходить бізнес-подію;
- listener створює typed context;
- trigger policy визначає recipient та eligibility;
- template resolver знаходить активний template;
- delivery gate перевіряє automatic delivery;
- channel resolver об’єднує template settings і user preferences;
- policy повертає NotificationDecision;
- tracked delivery резервує event key і виконує channels;
- результат фіксується як delivered, skipped, already delivered або failed.
Тести policy стають простішими
Policy можна тестувати без реальної mail або broadcast доставки:
- recipient відсутній - skip;
- permission відкликано - skip;
- template inactive - skip;
- global gate off - skip;
- mail вимкнений у preferences - mail немає в channels;
- database + broadcast дозволені - обидва повертаються.
public function test_mail_is_removed_when_user_opted_out(): void{ $decision = $this->policy->decide( $this->context( templateChannels: [ 'database', 'broadcast', 'mail', ], userChannels: [ 'database', 'broadcast', ], ), ); Listener повинен знати, що сталося. Policy повинен вирішити, чи потрібна нотифікація. Delivery service повинен безпечно виконати вже прийняте рішення.
Підсумок
Розкидані if у listener-ах працюють тільки поки notification rules прості. Коли з’являються templates, permissions, global gates, user preferences, кілька channels та idempotency, рішення краще зібрати в policy layer.
Це дає одне місце для бізнесового рішення, однакову поведінку для різних triggers, зрозумілі reason codes і простіші tests.
