Что такое монолитная архитектура приложения?

Давай разберём эту вавилонскую башню под названием «монолит», а то некоторые думают, что это что-то прочное, как скала. На деле-то это просто один большой, ебученный ком грязи, который все раскатывают по всему офису.

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

Как его опознать, этого красавца:

• Один репозиторий на всех: Весь код лежит в одной папке. Хочешь поменять кнопку — копайся в том же месте, где и логика расчёта кредитной ставки. Красота!
• Один процесс-монстр: Запускаешь один файл — и вуаля, твоё приложение живёт. А если упало, то упало всё, блядь, целиком. Ничего не уцелеет.
• Общая база данных — помойка: Все модули лезут в одну и ту же базу, как пьяные воробьи в кормушку. Один кривой запрос — и вся система хрипит.
• Связь намертво: Изменения в одном месте отзываются в другом таком, о котором ты и не подозревал. Сделал «фичу» в модуле пользователей — а бэк-офис у клиента встал колом. Ёперный театр!

Вот смотри, как это обычно выглядит в коде, простой пример на Flask:

from flask import Flask, request, jsonify
import sqlite3

app = Flask(__name__)

def get_db_connection():
    conn = sqlite3.connect('database.db')
    conn.row_factory = sqlite3.Row
    return conn

# Всё в кучке! И роуты, и бизнес-логика, и работа с БД — один сплошной спагетти-код.
@app.route('/api/users', methods=['GET'])
def get_users():
    conn = get_db_connection()
    users = conn.execute('SELECT * FROM users').fetchall()
    conn.close()
    return jsonify([dict(user) for user in users])

@app.route('/api/orders', methods=['POST'])
def create_order():
    data = request.get_json()
    # Тут же, блядь, рядом и логика заказов! Та же самая БД!
    # ...
    return jsonify({"status": "created"}), 201

if __name__ == '__main__':
    app.run(debug=True)  # И запускается всё это великолепие одной строчкой. Красота, да?

Чем это, блядь, хорошо на старте?

• Начал за здравие: Сегодня придумал, завтра уже пишешь. Не надо париться с кучей сервисов, их общением и прочей хуйнёй.
• Запустил — и забыл: Собрал один артефакт (jar, контейнер — неважно) и запустил. Проще некуда.
• Тестируется легко: Всё в одной памяти, можно целиком протестировать, не прыгая по сети.
• Быстро: Вызов из модуля в модуль — это просто вызов функции, а не поход через три прокси и два фаерволла. Скорость — овердохуища.

А теперь, сука, чем это плохо, когда проект вырастает:

1. Поддержка — пиздец: Код превращается в тот самый «big ball of mud» — большой ком грязи. Ничего не понять, всё связано. Новый разработчик смотрит на это и плачет.
2. Разработка тормозит: Исправил опечатку в тексте кнопки? Пересобирай и перезапускай ВСЁ приложение, ёбта! Каждая мелочь — деплой всего монстра.
3. Масштабирование — боль: Нагрузка только на модуль оплаты? Но масштабировать-то придётся ВСЁ приложение целиком, все его 100500 модулей. Деньги на сервера летят в трубу, как будто их нет.
4. Технологии — тюрьма: Всей команде навсегда назначен один стек. Хочешь попробовать новую крутую БД для аналитики? Да пошёл ты, вся система завязана на старую!
5. Отказоустойчивость — ноль: Сломался маленький модуль напоминаний о днях рождения? Привет, падение всего интернет-магазина! Доверия ебать ноль к такой системе.

Так когда же этот монстр — хороший выбор? Только на самом старте, для прототипа или для простого приложения, которое никогда не вырастет. Когда нужно быстро выкатить первую версию и не париться. Как только проект начинает жить и дышать — монолит превращается в того самого слоновьего мудака, которого все боятся и ненавидят.