Как представить обязательные бизнес-поля в структуре модели?

Я бы проверил необходимые свойства следующим образом:

public function listBookOfAuthor(Author $author) {

    if (empty($author->firstName)) {
        throw new listBookOfAuthorException('firstName must be defined');
    }

}

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

Что, если мы хотим сделать не весь объект, а только некоторые его атрибуты обязательными?

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

Просто потому, что это может иметь больше смысла в нашей бизнес-модели?

Я ничего не знаю о вашей бизнес-модели, поэтому не могу сказать, имеет она смысл или нет. Но я думал, что вы задаете вопрос о программировании, а не о бизнесе.

Должны ли мы всегда размещать ВСЕ объекты, несмотря ни на что?

Тогда вы потеряете подсказку типа, но сможете передать любой объект. Немного зависит от того, насколько строго вы хотите написать свой код. Если вы используете интерфейсы, вы достаточно гибки при рефакторинге кода (изменении конкретных реализаций объектов), а также при работе с объектом stclass. Однако с объектом stdclass функция должна проверить, что она получает в первую очередь, прежде чем обрабатывать входные данные функции.

В зависимости от вашей схемы, метод listBooksOfAuthor() (который выглядит как метод объекта службы, такого как BookService), вероятно, может быть достаточным только для объекта $authorId, а не для полного объекта Author.

Но, кажется, я понял суть вопроса. Возможно, полное заполнение объекта Author требует больших затрат — скажем, из метода, подобного AuthorService::getAuthorById().

В тех случаях, когда все, что вам нужно, это скромное подмножество Author функциональности, возможно, вы могли бы создать отдельный интерфейс - может быть, что-то вроде AuthorSummaryInterface - который отражает только те методы, которые вам нужны для этих обстоятельств. Разрешите объекту Author реализовать этот интерфейс, чтобы, когда у вас уже есть объект Author, вы могли выполнять операции, требующие только этой ограниченной функциональности Author. В качестве альтернативы вы можете создать метод Author:getSummary(), который возвращает конкретную реализацию AuthorSummaryInterface. В этом методе вы можете обеспечить соблюдение требований к членам — например, у них должно быть имя — и создать исключение, если эти требования не выполняются.

Вы также можете создать набор методов (например, для объекта AuthorService или объекта AuthorSummaryService), которые создают объекты AuthorSummary. Затем в тех случаях, когда требуется только AuthorSummaryInterface функциональность, вы можете создавать эти ограниченные функциональные возможности, менее дорогие в создании объекты.

Просто некоторые идеи.