Тоже об этом думал (вынос кейвордов), но что-то делать ничего не стал. И так вроде бы нормально, Cursive выдает подсказки по уже использованным кейвордам - выбираешь и всё. А если надо что-то порефакторить, SearchMonkey запущен, чтобы по всему проекту искать. А если киворды выносить, то есть подозрения что можно cyclic dependencies получить, плюс когда def используется, не сразу понятно, что там, киворд или какое-то нормальное значение, функция, или еще что, интуитивность пропадает.

Ну и вообще, JSON-driven development http://okigiveup.net/arguments-against-json-driven-development/, хоп-хоп и готово, все дела, а если киворды выносить, то так можно и до классов дойти

У неймспейснутых кейвордов есть неочевидное свойство (точнее у ридера)

(ns aaa)

::bbb

(ns ccc)

(require '[aaa :as a])

::a/bbb

то есть последний кейворд на самом деле :aaa/bbb

Такая особенность частично уменьшает проблемы с рефакторингом.

@leov я как раз думаю, как делать проекты не в 5 файлов и не 2 дня если эксперимент будет успешным - поделюсь результатами по поводу императивно или нет - это не важно на самом деле, важно подобрать модель, адекватную бизнес задаче пока сделал вот так: https://github.com/darkleaf/publicator/blob/master/src/publicator/interactors/user/log_in.clj#L38-L47 может быть, когда-нибудь я пойму как тут использовать чистый either отдельно either, отдельно бизнес задачу я понимаю, а вот как ее через either смоделировать - нет тривиальные случаи не рассматриваем)

@leov несколько мыслей накину: 0) сначала нужен дизайн системы в виде документа или рисунка. То есть разбивка на модули, входные и выходные данные каждого модуля. 1) На вход разработки по-любому поступает что-то от аналитиков, которые хотя бы в табличке описали модель предметной области данных. Разработка предметной модели данных в Clojure собственно представление этих данных в виде мап с неймспейсами или Record'ов. 2) тесты никто не отменял в clojure. Делаем REPL-driven development при разработке кода. После того как убедились в REPL' е что все работает, по shortcut создается пространство в папке test, куда с небольшими изменениями переносится код, вызыванный в REPL'е в виде unit-тестов. 3) Спека очень подходит для межмодульного тестирования. Соответственно, она поможет предотвратить опечатки и выкинет exception при первом запуске неверных данных. 4) Опечатки как правило видны сразу при REPL-драйвен. А если сосед опечатался, то unit-тесты на то и нужны, чтобы он локально убедился что код соседей не сломал.