Автор: Вячеслав Михайлов
Монолитные приложения и их проблемы
Все прекрасно знают, что такое монолитное приложение: все мы делали такие двух- или трехслойные приложения с классической архитектурой:
Для маленьких и простых приложений такая архитектура работает прекрасно, но, допустим, вы хотите улучшить приложение, добавляя в него новые сервисы и логику. Возможно, у вас даже есть другое приложение, которое работает с теми же данными (например, мобильный клиент), тогда архитектура приложения немного поменяется:
Так или иначе, по мере роста и развития приложения, вы сталкиваетесь с проблемами монолитных архитектур:
- сложность системы постоянно растет;
- поддерживать ее все сложнее и сложнее;
- разобраться в ней трудно — особенно если система переходила из поколения в поколение, логика забывалась, люди уходили и приходили, а комментариев и тестов нет);
- много ошибок;
- мало тестов — монолит не разобрать и не протестировать, поэтому обычно есть только UI-тесты, поддержка которых обычно занимает много времени;
- дорого вносить изменения;
- застревание на технологиях (например, я работал в компании, где с 2003 г. технологии до сих пор не изменились).
Рано или поздно вы понимаете, что уже ничего не можете сделать со своей монолитной системой. Заказчик, конечно, разочарован: он не понимает, почему добавление простейшей функции требует нескольких недель разработки, а затем стабилизации, тестирования и т. д. Наверняка многие знакомы с этими проблемами.
На ночь глядя RSS reader (кстати, 
