Куда может завести "свой DSL". Часть 3. Резюме.

Как я сказал в предыдущей части, неразрешимых проблем с языком не было. Более того, его пытались даже использовать для написания триггеров уровня приложения, целей экспорта данных из наших систем в другие.
Но шло это всё с большим "скрипом", поскольку "отчётная заточенность" языка давала о себе знать на каждом шагу.
Внимательный читатель сразу вскинется: "Позвольте! Так и должны быть проблемы! Ведь DSL в силу своей domain-specific совершенно не предназначен для решения задач из другой предметной области!" и, возможно, в запале добавит: "Для другой предметной области нужен другой DSL!"

О Fluent-интерфейсах

В контексте недавно состоявшегося обсуждения (здесь, и ранее, здесь) у меня возникли основания порассуждать для себя об области применимости fluent-техники.

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

Но достаточно быстро стало понятно, что техника подходит не для всего на свете.

Собственно, «крайние» мысли на этот счёт изложены ниже.

Собственно, вопрос. Не стоит ли смотреть на fluent-технику как на DSL?

Она выглядит как DSL и правила работы с ней напоминают правила работы с DSL.

Только DSL в контексте существующего языка.

Вероятно, это не просто увидеть, поскольку обычно DSL реализуется средствами другого языка.