Количество вызовов от Facade в Facade Pattern

Количество вызовов внутри Фасада не должно иметь значения, пока вызов выполняет одну единственную операцию (в глазах вызывающего) и выполняет ее полностью.

Имейте в виду, что одна операция с вызывающей стороной может включать ведение журнала, выполнение бизнес-правил, открытие соединения с базой данных, запись в базу данных, а затем, наконец, закрытие и очистку соединения.

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

Если это только один вызов, эти слои должны быть объединены в один слой.

Являются ли слои Facade и Orchestration слабо связанными? Если это так, то мой ответ будет «нет», не объединяйтесь. Просто с точки зрения принципов я думаю, что в слабой связи есть ценность, и ее следует сохранить.

Должен ли фасад иметь только один вызов уровня оркестровки или все в порядке с несколькими вызовами.

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

Однако я бы позволил провести различие между чисто «деловыми» звонками и «сквозными» звонками. Установив соглашение о том, что только один «деловой» вызов может быть «пропущен» через Фасад, вы сохраняете чистую структуру бизнес-служб (никогда не возникает путаницы); но, с другой стороны, технически вы не ограничены в выполнении других сквозных вызовов, которые улучшают поведение и возможности системы.