можно использовать Project Reactor дабы избавиться от коллбек хелла

а что там вместо коллбеков?

Если у тебя CF или Mono/Flux то откуда берется callback hell?  Если сервис у тебя реактивный то он весь пронизан Mono/Flux(как пример) а если у тебя зачем то один слой доступа к базе данных сделан реактивным и не хочется тянуть наверх реактивщину то надо его выкинуть и делать все по старинке или просто делать на вызовах типа blockOptional и ждать результата

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

когда я начинаю собирать данные из нескольких асинхронных методов и передавать их в другие асинхронные методы а потом в следующие (но не вложенные) при этом изменяя их в текущем слое тоже

пример покажи - как ты во Flux колбек можешь засунуть а внтури его еще колбек?

моя абстракция - это средство формализации и декомпозиции бизнес- процесса, если её выкинуть всё сольётся в один большой клубок

просто посмотри как работать с Flux/Mono и пойми что такое реактивщина вообще такое и для чего она нужна. пока что сплошная каша - ты даже не хочешь открыть какой нить простой туториал типа https://www.baeldung.com/reactor-core чтобы понять что к чему

реактивщиной я не пользовался  а на фьючах например такое часто происходит

return repository1.findAll().thenCompose(items -> {
    return repository2.doSomething(items).thenCompose(result -> {
        return repository3.doSomethingWithBoth(items, result);
    })
})

сделай простую цепочку

убери скобки и ретурны и будет уже проще.  без реактивщины будет код не намного лучше.

на что конкретно я должен обратить внимание?

сделать простую цепочку не получится так как третий этап зависит от первого, это не позволяет зачейнить thenCompose

на все :) ты должен стремится сделать свой поток данных как можно проще ну и использовать реактивщину понимая для чего она. нет смысла от асинхроного Постгрес драйвера если дальше все сделано на thread per request

тогда разбивай на функции чтобы облегчать понимае типа repository1.findAll().flatMap(this::doSomething)

в какой момент речь перешла на реактивщину? я раньше ей не пользовался и сейчас асинхронщина у меня реализована на фьючах, зачем мне приплетать ещё и mono, что мне это даст? у меня по прежнему есть монада, только она называется не CompletableFuture а Mono и есть сабскрайберы которые подписываются на её выполнение, и чейнятся я получаю возможность стримить данные, отдавая их сериями через Flux, но это не то что мне нужно, я по прежнему имею ограничения на доступ к данным и кучу коллбеков

как по мне то ты занимаешься демагогией. У тебя есть что то возращающее фьючу - это сделал явно не я.  но тебе как то с этим надо работать а не плакать что у тебя проблемы с доступом.  я сказал несолько раз - от асинхрощины нет смысле если у тебя не все асинзронное и нет понимания зачем это вводится. Mono/Flux я предлагаю тк с ними гораздо удобней работать чем с Фьючами. Плюс куча библиотек работают именно с ними.  Ограничений у тебя вообще нет - тебе просто не нравится код который получается толи потому что у вас архитектура кривая толи потому что тебе просто асинхронщина не нравится.

те к примеру для меня такой код https://pastebin.com/EtZqk7as понятный и простой

и особо разницы между блокирующим кодом нет.

я понял тебя, меня беспокоит не неподходящая реализация монады и не отсутствие понимания реактивщины

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