Memento mori


Год назад мой брат Андрей рассказал про доклад Design for Repleceability  на конференции JavaZone. Вчера в разговоре он опять вспомнил про неё и я наконец посмотрел его и настоятельно советую его теперь посмотреть всем.
The most important question to be asked when developing a new software system is «How will we replace it?» It is however a question seldom asked. Instead organization focus on reusability, which unfortunately helps create rigid and inflexible architectures. The talk shows how to design systems made up of small parts, why you should standardize on protocol and not platform and how you will end with a system that is easier to scale and maintain.
В двух словах идея следующая: Если вы будете думать о смерти своего продукта то он станет лучше. А проект умрёт, причём довольно быстро.
Если вы напишите программу которая будет проживёт десять лет то вы станете очень богатым человеком
Так вот, чтобы не переписывать всю систему, то нужно использовать SOA архитектуру и разбивать на отдельные приложения-модули, например модуль авторизации, модуль админки и публичная часть сайта.
В любой момент вы можете заменить модуль, переписать его на новых технологиях а то и вовсе на другом языке программирования.
При этом если они все модули работают с одной базой то это всё равно одно приложение, потому что вы не можете безопасно отключить его и делать с ним всё что захотите.
Модули будут общаться по протоколу. Желательно очень простой протокол типа REST+JSON а не замудрённый SOAP.
Но у REST нет такого механизма для описания своих параметров и методов как WSDL файлы в SOAP.
На самом деле есть — WADL, но о нём никто вообще не знает и похоже стандарт мёртв.
Для решения этой проблемы вы просто на каждый сервис генерируете обычную XHTML страничку со всеми параметрами запроса. Любой человек сможет её понять.
Поскольку ваши приложения живут независимо то вы получаете горизонтальное масштабирование и устойчивость к падениям.
Кроме горизонтального масштабирования приложения вы ещё получаете горизонтальное масштабирование команд: каждое приложение может делать отдельная маленькая гипер-продуктивная команда из трёх-семи человек, причём если у вас например нет возможности нанять зажравшихся явистов можете набрать команду из школьников PHP’ешников и выделить их в отдельную команду.

Один комментарий

  1. Уведомление: Как жить на Legacy проекте | stokito on software

Оставьте комментарий