Constructor OutgoingMailGovernor

Namespace

MailFathom.Application.Mail.Delivery.Governance

Assembly

MailFathom.Application.dll

OutgoingMailGovernor(IOutgoingSendPermissionReader, OutgoingRecipientPolicy, OutgoingMailCeilings, IOutgoingMailUsageReader, TimeProvider)

Decides whether this deployment may send a message at all, before a record of it exists.

public OutgoingMailGovernor(IOutgoingSendPermissionReader permissions, OutgoingRecipientPolicy recipientPolicy, OutgoingMailCeilings ceilings, IOutgoingMailUsageReader usage, TimeProvider timeProvider)

Parameters

permissions IOutgoingSendPermissionReader

Says whether this deployment may send as the account the request names.

recipientPolicy OutgoingRecipientPolicy

Says who this deployment may write to.

ceilings OutgoingMailCeilings

Says how much one period may be asked to send.

usage IOutgoingMailUsageReader

Counts what the period has already been asked for.

timeProvider TimeProvider

Decides which period the present moment belongs to.

Remarks

Three questions in one place because they are one decision with one answer: whether the capability is held, whether the people named may be written to, and whether the period has room. Each is the operator's rather than any author's, so a caller, a rule, a command, and a protocol added later all meet them identically.

It is asked by the outbox rather than by an entrypoint, which is what makes it unbypassable: enforcing any of the three in a caller would leave the caller added next to re-enforce it, and a bound with as many implementations as it has callers is a bound with as many holes.

The order is capability, recipients, ceiling, and it is the order of cost. A deployment that cannot send is answered without reading anything; a policy refusal is decided in memory; and only a send that has passed both reads the period's counts from the database, which a deployment declaring no ceiling never does at all.