Не знаю, к какой книге вы обращаетесь, но я знаю, что книги, как правило, предпочитают архитектуру с свернутыми слоями или шестиугольными.
Рассмотрим следующие слои (зависимости исходного кода):
UI -> Application/Domain <- Infrastructure
Обратите внимание, как зависимости указывают внутрь ядра вашего приложения. Если это вас смущает, то здесь используется «принцип инверсии зависимостей» - разделение политик высокого уровня (приложение / домен) и реализаций низкого уровня (ниже).
В этом случае не было бы проблем с планированием заданий или чего-то подобного, которые вызывают какую-то прикладную службу, поскольку инфраструктуре «разрешено» получать доступ к логике c, предлагаемой вашим ядром.
Я не уверен, что это то, что вы имели в виду, но в целом к слою DDD применимо следующее: инфра-слой в DDD предлагает реализации для ВСЕХ связанных с инфраструктурой интерфейсов во ВСЕХ уровнях, поэтому его можно рассматривать как несколько «окружающий» внешний слой.