Ущербно-ориентированное программирование

Счёт-фактура выставляется продавцом покупателю. Wiki.

А вы говорите, что счёт выставляется клиенту.

Если счёт всегда выставляется покупателю, то зачем конкретизировать, что счёт покупателя? Или всё-таки продавца? Или всё-таки я говорил о системе, когда клиенту моего сервиса выставляется счёт и в этом случае уточнение, что счёт клиента не имеет смысла вдвойне? В этом конкретном методе я этого не уточнял. Возможно, уточнение есть в имени класса или неймспейсе.

Смысл паттерна как, раз таки в том что программисту без разницы сколько валют в системе. Деньги это никогда не просто количество, это именно количество в определенной валюте. То что она в системе одна и используется по умолчанию никак этого не отменяет.

Т.е. у нас есть виртуальная валюта, не пополняемая извне, но мы всё равно таскаем везде валюту? Бессмысленно.

Я привел абстрактный пример. Вы сделали из него выводы относительно вашей системы.

Вы в ответ на мой пример привели свой, уточнив, что в моём примере непонятно, что это за аккаунт. Т.е. изначально вы отклонились от моего утвержденя «любой аккаунт» и начали предполагать и конкретизировать.

Я в примере показал только то что именовать аргументы в соответствии с именами их классов, имхо, масло-масленное и дурной тон.

Именовать аргументы классом — это хорошая практика:

\Dbal\Driver\Configuration $db — плохо
\Dbal\Driver\Configuration $dbConfiguration — хорошо

string $country — плохо
string $countryName — хорошо (уточняем класс строки — имя, хоть он и не является отдельным классом в коде)
при этом $countryString — плохо (но лучше, чем $country), т.к. всё ещё не даёт понимания, что это за строка.

Account $customer — плохо,
Account $customerAccount- хорошо.

UserGroup $owner — плохо,
UserGroup $ownerGroup — хорошо.

addUser(User $user) — хорошо,
setAccount(Account $account) — хорошо,
setCustomerAccount(Account $account) — хорошо,
setCustomerAccount(Account $customerAccount) — хорошо.

Часто оказывается, что и
User $owner — плохо
User $friend — плохо
если в системе присутствуют классы, вводящие двусмысленность (UserGroup, UserFriend, и т.п.)

В итоге именование с постфиксированием классом объектов всегда является более выгодным решением, т.к. в случае коллизии вам либо всё равно придётся играть с уточнениями постфиксированием, но будет каша, либо в итоге всё вообще встанет с ног на голову:

function createInvoice(Account $customer, $amount)
{
   $user = $customer->getUser();
   Mailer::create()->send($customerUser->getEmail(), 'You have new incoming invoice.');
}

В моём варианте это будет выглядеть так:
function createInvoice(Account $account, $amount)

{
   $user = $account->getUser();
   Mailer::create()->send($user->getEmail(), 'You have new incoming invoice.');
}

В любой системе есть некие «главные действующие лица» (обычно это пользователи, устройства, компании, сайты и т.п.). Всем остальным приходится постфиксироваться, чтобы не конфликтовать с главными действующими лицами.

$user
$userAccount
$userGroup
или
$account
Money $accountBalance (интуитивно понятно)
Currency $accountCurrency
Contacts $accountContacts