Именование должно действительно исходить из того, что делает метод.Сделайте шаг назад и сначала посмотрите на Разделение команд-запросов (CQS) .То, что вы действительно пытаетесь сделать здесь, это убедиться, что любой данный метод либо запрашивает данные, либо указывает, что что-то происходит.
Т.е. "Запрашивать значение не следуетизменить значение ".
CQRS - это нечто иное, в большем масштабе и, как правило, менее понятное.Однако это не обязательно сложно, просто применяя концепцию CQS на уровне архитектуры, а не на уровне кода.Например, вы можете выбрать WCF для команд и необработанный SQL для запросов.Он направлен на то, чтобы дать вам свободу сделать ваши запросы максимально простыми, которые могли бы работать, в то время как ваши команды все еще получают богатство полной доменной модели или другой подходящей реализации для ваших бизнес-правил.
CQRS также направляет васот приложения CRUD до приложения, основанного на задачах, где вы сосредотачиваетесь больше на проблемной области с точки зрения взаимодействия с пользователем, чем просто чтения и сохранения данных.
Запросы
Как правило, я называю "запросы"вариации FindXYZ(), GetXYZ() или LoadXYZ, при условии, что цель ясна (то есть возвращает некоторые данные, не изменяет any).
Команды
Обычно называть команды сложнее, хотя вы можете думать так же, как в соглашениях по именованию командлетов PowerShell - verb-noun.Лично я склонен реализовывать команды в виде шаблона CommandProcessor, где команды на самом деле являются объектами, содержащими параметры (иногда только первичный ключ объекта).Существует код для поиска соответствующих «процессоров» для каждой команды Type.Как правило, в CQRS вы пытаетесь поддерживать это синхронно, потому что асинхронность означает, что вам нужно проделать большую работу по обработке команд, которые не удалось обработать, но если вам действительно нужна команда для асинхронности, то обработчик вашей команды может отправитьсообщение для ESB, чтобы сделать это.