Структура приложений

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

А насчет нормального функционального языка тоже не очень согласен. Имхо, вся мощь Scala в том, что она и FP и OOP одновременно.

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

То есть сам иевангилист DDD ничего не имеет против размещения логики в сервисах. И при этом заметь твой FlightBooker не относится ни к одному из трех видов доменной модели описанных Эвансом, это не сущность не сервис и не объект значение. Вводя FlightBooker ты не следуешь DDD так как логика уже отдельно данных, а именно это дэдэдэшники и считают основной его фичей, но твоё решение точно так же как и решение с помещением логики в сервис вполне практичное и работоспособное.

Если существенно важный процесс или преобразование в модели не относится к ес­
тественным обязанностям объекта-сущности или ЗНАЧЕНИЯ , добавьте в модель эту
операцию с отдельным интерфейсом и назовите ее СЛУЖБОЙ. Определите интерфейс
н а языке модели и сделайте имя операции элементом ЕДИНОГО ЯЗЫКА. У СЛУЖБЫ не
должно быть собственного состояния.