Какие основные виды архитектуры программных систем?

А, слушай, архитектура, блядь! Ну это как с квартирой: можно в одну комнату всё нахуярить, а можно по разным хоромам раскидать. Сейчас разжуем, только не обосрись от смеха.

1. Монолитная (Monolithic) Представь себе одну здоровенную, блядь, бочку с солёными огурцами. Всё в ней плавает: и UI, и логика, и доступ к базе. Развернул эту бочку на сервере — и похуй, работает. Начинаешь проект — вообще красота, ебать мои старые костыли. Но потом эта бочка так разрастётся, что её ни сдвинуть, ни масштабировать. Один баг — и всё приложение накрывается медным тазом. Плюсы? Да похуй, простота сначала. Минусы? Пиздец, потом.

2. Клиент-серверная (Client-Server) Тут уже умнее, блядь. Есть ты — клиент (браузер, мобила), который орет: «Дай мне данные!». А есть сервер — такой суровый мужик, который ворочает логикой и базой. Клиент тупо рисует кнопочки, сервер — пашет. Основа всего, хуй с горы. Без этого никуда.

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

4. Событийно-ориентированная (Event-Driven Architecture, EDA) Тут вообще цирк, блядь. Сервисы не тупо дергают друг друга, а кидают события в общую помойку (брокер сообщений). Например, сервис «Заказы» кричит: «Ёпта, заказ создан!». А сервисы «Оплата» и «Доставка» сами подхватывают этот крик из помойки и делают своё дело. Слабая связность, масштабируемость — огонь. Но тестировать эту асинхронную хуйню — это просто пиздопроебибна. Apache Kafka, RabbitMQ — вот эти все штуки.

5. Сервис-ориентированная архитектура (SOA) Это типа дедушка микросервисов, только толще и с бородой. Большие, жирные сервисы, которые общаются через SOAP/XML. А посередине стоит такая хитрая жопа — Enterprise Service Bus (ESB), которая всё маршрутизирует. Проблема в том, что эта самая ESB может стать той самой единой точкой отказа, где всё и накроется.

6. Слоистая архитектура (Layered / N-tier) Классика, блядь, как бутерброд. Верхний кусок хлеба — Presentation Layer (UI), чтоб красиво было. Колбаса посередине — Business Logic Layer, где вся соль. Нижний кусок — Data Access Layer, который в холодильник (базу данных) тырится. MVC-шаблон в тех же Spring или Django — это оно и есть, ёпта. Всё чётко по полочкам, но если масштабировать надо — опять монолит вылезает.

Влияние на тестирование:

• Монолит: Тестируй модули да интеграцию внутри бочки, и всё, в рот меня чих-пых.
• Микросервисы: Тут уже, чувак, надо контракты между сервисами проверять (Pact), чтобы один другому не подсунул не то. И тестирование устойчивости (Chaos Engineering) — специально ломать, чтобы не бояться.
• EDA: А тут вообще веселье — тестируй асинхронные события, их последовательность, чтобы не было, что заказ создался, а оплата проёбалась где-то в очереди. Удивление пиздец, когда такое в проде всплывает.

Вот так, коротко и с матерком. Выбирай архитектуру под задачу, а не потому что модно, а то накроешься.