January 29th, 2010

glider

Об ad-hoc подходе к архитектурированию

Вчера имели с zamotivator любопытный разговор. Обсуждали его идею по ad-hoc архитектурированию оперденей в плане: бизнес-логика частично в СУБД (вьюшки, хранимки) и частично в миддл-тире (строковые сиквел запросы и клей на general-purpose ФЯ по вкусу). Как я понял, UI в таком подходе девелопится полностью независимо от доменной модели, т.е. просто пишется пачка контролов под данную аппликуху, и они потом собираются в формочки и наполняются данными через RPC-запросы к миддл-тиру.

При таком подходе для разработки необходим минимальный набор тулов: html, js + qooxdoo/jquery/другой js-либ, json-rpc, sql и general-purpose ФЯ по вкусу (Олег предлагает использовать erlang ввиду его несложности и отличной масштабируемости). Все остальные фреймворки, например, O/R-мапперы, по мнению Олега, излишни так как нарушают принцип KISS и порождают протечку абстракций.

***

Мое мнение несколько отличается. Ессно, я согласен с тем, что зачастую архитектура оперденей зело усложняется желанием подъюзать кучу модных фреймворков, не подумав о том, как их подружить и как защищаться от протечек абстракции. В итоге получаются конфликты на стыках тиров, нереальное количество бойлерплейта и неиллюзорный butthurt.

С другой стороны, я не согласен с тем, что выход отсюда находится в ad-hoc проектировании, ибо для последнего имеем следующую цепочку. Disclaimer: все, сказанное ниже, становится проблемой только тогда, когда прилага достигает определенного порога сложности. Простые программки, на мой взгляд, можно и нужно лабать в ad-hoc стиле.

1) Доменная логика расползается по коду, да еще и по разным тирам, что требует склейки через RPC и ведет к разделению неймспейса программы по разным модулям и разным языкам.

2) Это влечет за собой экспоненциальный рост сложности понимания программы (несмотря на то, что underlying принципы остаются простыми), так как вместо фтыкания в концентрированный код бизнес-логики аля на картинке программист вынужден искать и сопоставлять куски кода из разных тиров: UI (валидация, маршаллинг параметров на миддл-тир), миддл-тира (строковые сиквел-запросы) и БД (вьюшки, хранимки). Мало того, что в навигации между этими кусками не поможет никакая IDE, так еще и написаны эти куски обычно на разных языках и в физически разных файлах, что значительно затрудняет получение целостной картины кода. Это я еще не говорю про дебаг.

3) Расползание бизнес-логики между тирами и языками ведет и к тому, что ее становится трудно реюзать (строковые сиквел-запросы особо не пореюзаешь, кроме того, сам SQL, мягко говоря, не настолько хорошо подходит для структуризации программ, как современные general-purpose языки). Код также становится сложно рефакторить (а что если для рефакторинга нужно написать скрипт обновления базы, поменять несколько десятков строковых SQL-запросов, перетусовать немного кода между тирами и заодно обновить RPC-склейку? по себе знаю, что тупо становится влом).

4) Затруднения в реюзе ведут к накоплению дублирования, затруднения в рефакторинге ведут к накоплению энтропии. Это выливается в экспоненциальный (в метафорическом смысле, конечно) рост стоимости внесения изменений, что после некоторого порога сложности превращается в натуральный адЪ.