Ага. Тут и да, и нет. FPF на то First principles, что задачу (а лучше даже проблему) есть возможность сформулировать на самом верху абстракций, на естественном языке. В этом же смысле, все языки программирования решают задачи, которые люди обычными словами описывают. И про классы задач я бы тоже поспорила, узко профильные языки есть, но все остальное распределение довольно мало зависит от “потому что вот это максимально удобно и правильно делать ровно вот этим инструментом”.
Я к тому что классы решаемых фреймворком задач довольно широкие и от предметной области мало зависят. Потому что “принятие решений” какую БД выбрать для реализации фичи M, какую клинику выбрать для лечения собаки, в какой вуз поступать подростку это всё класс задач - принятия решений. И его FPF вполне покрывает.
А “трудоемкость написания кода” она как будто не на вашей стороне. Тут есть уровень формальности описания, вот вам модель насыпала холонов, эпистем, оно вам надо? Если интересно, как системному программисту в регистрах процессора ковыряться, ковыряйтесь. Если не интересно, надо просить отвечать “по-человечески” на языке инженеров-менеджеров. И внутрисистемный сленг исчезнет…
Вообще автор обещает(ся) цикл семинаров про FPF, чтобы магия перестала быть магией. Ждём)