Naming conventions are an architecture decision

Names tell you the layer before you open the file

Naming conventions look like a style preference until you try to find every class that touches Account in a codebase with four hundred of them. Then they look like architecture. Search is only as good as the names you are searching for. A consistent name tells you the layer, the object and the job before you open the file. An inconsistent one tells you only that three teams were here, none of them spoke to each other, and one of them really liked the word Helper.

AccountSelector          // queries only, no DML
AccountService           // business logic, singleton
AccountOwnershipModule   // trigger logic, one concern
AccountTriggerHandler    // dispatch, nothing else
AccountServiceTest       // one test class per class
CaseRoutingQueueable     // async work, suffix says so
PricingCalloutService    // callouts isolated, easy to fake
Order_Status_Changed__e  // events named in past tense

The value is not in the specific pattern. It is in having one, enforcing it in CI, and refusing exceptions for the urgent thing. A regular expression in a pipeline costs an afternoon. Renaming a hundred classes in a live org costs a quarter, a change freeze and several apologies, because metadata names leak into flows, reports and integrations. New starters learn the pattern in a day, and agents follow it without being asked. Enforce the standard early, while it is still cheap.