IT GARDEN

ПРОСТЫМИ СЛОВАМИ
О СЛОЖНЫХ ТЕРМИНАХ

СЛОВАРЬ

®

Представьте, что вы организуете свадьбу. У вас есть разные группы людей, которым важно, чтобы всё прошло хорошо, но у каждого свои интересы:

Стейкхолдеры — это как гости на свадьбе, у каждого свои интересы и ожидания.

Это все люди или группы, которые заинтересованы в проекте: заказчики, пользователи, разработчики, тестировщики, менеджеры и т.д. У каждого свои цели и ожидания от проекта, и важно учитывать их при принятии решений.

Так же работают стейкхолдеры в IT :

Стейкхолдеры — это все, кому важен успех проекта, но у каждого свои интересы, которые нужно учитывать, как на свадьбе.

Проще говоря:

молодожёны (основные участники) хотят, чтобы праздник был красивым и запоминающимся;

родители могут настаивать на традициях или определенных гостях;

официанты заботятся о том, чтобы еда была подана вовремя;

фотограф хочет, чтобы все были на своих местах для идеальных снимков;

гости ожидают вкусной еды, музыки и веселья.

Бизнес-требования — это как пожелания владельца ресторана.

Представьте, что владелец пиццерии говорит: "Мы хотим продавать больше пиццы и привлечь больше клиентов". 

Это общая цель бизнеса — увеличить продажи и улучшить сервис.

В IT Бизнес-требования описывают цели компании или проекта, например: "Система должна повысить конверсию на 20%" или "Увеличить количество активных пользователей".

Пользовательские требования — это как пожелания клиента в ресторане.

Теперь представьте клиента, который приходит в пиццерию и говорит: "Я хочу пиццу с грибами, без лука, и чтобы она была горячей". Это конкретные запросы пользователя, которые помогут ему получить желаемый результат.

В IT пользовательские требования описывают, что именно нужно пользователям для работы с системой, например: "Пользователь должен иметь возможность войти через Google", "Кнопка заказа должна быть крупной и заметной".

Бизнес-требования — это стратегия (цель), а пользовательские требования — тактика (что именно нужно сделать для достижения этой цели).

Проще говоря:

Бизнес-требования — это зачем : "Хотим продавать больше пиццы".
Пользовательские требования — это как : "Пицца должна быть с грибами, без лука, и доставлена за 30 минут".

Простое сравнение:

Бизнес-требования и пользовательские требования

Пользователь может войти в систему. 

Система отправляет email-уведомления. 

Кнопка 'Поиск' находит нужные товары по ключевым словам.

Это конкретные функции, которые машина обязана выполнять.

Нефункциональные требования — это как машина должна работать.

В IT: Функциональные требования описывают конкретные возможности системы. Например:

Страница загружается за 2 секунды.

Система поддерживает одновременную работу 1000 пользователей.

Данные пользователей шифруются согласно GDPR.

В IT: Нефункциональные требования описывают характеристики работы системы. Например:

Она должна разгоняться до 100 км/ч за 8 секунд (производительность).

Расход топлива не должен превышать 7 литров на 100 км (эффективность).

Машина должна быть безопасной и соответствовать стандартам безопасности (безопасность).

Интерьер должен быть удобным для длительных поездок (удобство).

Теперь представьте, что вы ожидаете от автомобиля:

Функциональные требования — это что машина должна уметь делать :

Машина должна заводиться с кнопки. 

Она должна иметь навигационную систему. 

В багажнике должно помещаться 4 чемодана. 

Представьте, что вы выбираете автомобиль и говорите:

Проще говоря: "Как система должна работать?"

Проще говоря: "Что система должна уметь делать?"

Функциональные и нефункциональные требования

Простое сравнение:

Функциональные требования : "Машина должна заводиться с кнопки и иметь навигацию".
Нефункциональные требования : "Машина должна быть быстрой, экономичной и безопасной".

Так же работает нормализация базы данных :

Это процесс организации данных в таблицы так, чтобы избежать дублирования (как если бы вы складывали одни и те же носки в разные ящики).

Данные разделяются на связанные таблицы, где каждая хранит только уникальную информацию (например, одна таблица для клиентов, другая для заказов).

Это помогает избежать "хаоса" в данных и делает работу с ними удобной и эффективной.

Связь один к одному в базе данных — это как человек и его страховой полис.

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

Нормализация базы данных — это как аккуратная организация шкафа, чтобы всё было на своих местах, без лишних повторов.

Простое сравнение:

Представьте, что у каждого человека есть только один личный страховой полис, и этот полис выдан именно ему. Никто другой не может использовать этот полис, и у человека не может быть двух таких полисов одновременно.

Связь один к одному в базе данных — это как человек и его страховой полис.

Это все люди или группы, которые заинтересованы в проекте: заказчики, пользователи, разработчики, тестировщики, менеджеры и т.д. У каждого свои цели и ожидания от проекта, и важно учитывать их при принятии решений.

Так же работает связь один к одному в БД :

Представьте, что у каждого человека есть только один паспорт, и каждый паспорт выдан ровно одному человеку. Нельзя иметь два паспорта для одного человека, и один паспорт не может принадлежать двум разным людям. Это строгая связь "один к одному".

Связь один к одному в базе данных — это как паспорт и человек.

Это все люди или группы, которые заинтересованы в проекте: заказчики, пользователи, разработчики, тестировщики, менеджеры и т.д. У каждого свои цели и ожидания от проекта, и важно учитывать их при принятии решений.

Так же работает связь один к одному в БД :

Связь один к одному — это когда одна запись в одной таблице связана строго с одной записью в другой таблице, как человек и его паспорт.

Проще говоря:

Связь один к одному — это когда одна запись в одной таблице (человек) связана строго с одной записью в другой таблице (его страховой полис).

Проще говоря:

один сотрудник имеет только один пропуск;

и один пропуск выдан только одному сотруднику.

Например, у таблицы "Сотрудники" может быть связь с таблицей "Пропуска на территорию":

у каждого студента есть только одна зачётная книжка;

и каждая зачётная книжка принадлежит только одному студенту.

Например, у таблицы "Студенты" может быть связь с таблицей "Зачётная книжка":

Представьте, что у одного дома есть несколько комнат. Все комнаты принадлежат этому дому, но каждая комната связана только с ним. Другой дом тоже имеет свои комнаты, но они никак не связаны с первым домом.

Связь один ко многим в базе данных — это как дом и его комнаты.

Так же работает связь один ко многим в БД :

Представьте, что у одного дерева есть много листьев. Все листья принадлежат этому дереву, но каждый лист связан только с ним. Другое дерево тоже может иметь свои листья, но они не пересекаются.

Связь один ко многим в базе данных — это как дерево и его листья.

Так же работает связь один ко многим в БД :

Связь один ко многим — это когда одна запись в одной таблице (дерево) связана с несколькими записями в другой таблице (листья), но каждая из этих записей связана только с ней.

Проще говоря:

Связь один ко многим — это когда одна запись в одной таблице (дом) связана с несколькими записями в другой таблице (комнаты), но каждая из этих записей связана только с ней.

Проще говоря:

Один клиент может сделать много заказов.

Но каждый заказ принадлежит только одному клиенту.

Например, у таблицы "Клиенты" может быть связь с таблицей "Заказы":

один проект может включать много задач;

но каждая задача относится только к одному проекту.

Например, у таблицы "Проекты" может быть связь с таблицей "Задачи":

Представьте, что в школе есть ученики и разные кружки (например, рисование, шахматы, танцы). Один ученик может посещать несколько кружков (например, рисование и шахматы), а в каждом кружке могут быть несколько учеников.

Связь многие ко многим в базе данных — это как ученики и кружки.

Так же работает связь многие ко многим в БД :

Представьте, что у вас есть актёры и фильмы. Один актёр может сняться в нескольких фильмах (например, Леонардо ДиКаприо снимался в "Титанике", "Волке с Уолл-стрит" и других), а один фильм может включать множество актёров (например, в фильме "Мстители" снимались десятки актёров).

Связь многие ко многим в базе данных — это как актёры и фильмы.

Так же работает связь многие ко многим в БД :

Связь многие ко многим — это когда одна запись в одной таблице (актёр или учитель) связана с несколькими записями в другой таблице (фильмы или предметы), и наоборот.

Проще говоря:

Связь многие ко многим — это когда одна запись в одной таблице (ученик или книга) связана с несколькими записями в другой таблице (кружки или авторы), и наоборот.

Проще говоря:

один учитель может преподавать несколько предметов (например, математику и физику);

один предмет могут преподавать несколько учителей.

Например, у таблицы "Учителя" может быть связь с таблицей "Предметы":

одна книга может быть написана несколькими авторами.

один автор может написать несколько книг.

Например, у таблицы "Книги" может быть связь с таблицей "Авторы":

AS IS и TO BE процессы — это как ремонт в квартире.

Представьте, что вы живёте в квартире, которая уже обжита, но не совсем устраивает вас по удобству или внешнему виду:

Так же работают AS IS и TO BE процессы в бизнесе или IT :

AS IS описывает текущие процессы, как они работают сейчас, с их проблемами и ограничениями.

TO BE описывает, как эти процессы должны работать в будущем, чтобы стать эффективнее, удобнее или современнее.

AS IS — это "как есть", а TO BE — это "как должно быть"

Проще говоря:

AS IS — это текущее состояние вашей квартиры. Например, старая планировка: кухня маленькая, гостиная захламлена, а света не хватает. Это то, как всё работает сейчас, со всеми недостатками.

TO BE — это план вашей квартиры после ремонта. Вы хотите сделать просторную кухню-гостиную, добавить больше света, перенести стены и установить новую мебель. Это будущее состояние, которое вы хотите достичь.

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

Экземпляр бизнес-процесса — это как конкретная поездка на такси.

Экземпляр бизнес-процесса — это как конкретная реализация общего процесса, например, одна конкретная поездка такси из множества возможных.

Проще говоря:

Так же работает экземпляр бизнес-процесса :

Бизнес-процесс — это общий шаблон действий (например, "обработка заказа клиента").

Каждый конкретный заказ клиента — это отдельный экземпляр этого процесса, со своими данными и особенностями.

завтра вы едете с работы в кафе (другой экземпляр того же процесса).

каждая поездка уникальна: разные точки отправления и назначения, разное время, разные водители, но все они следуют одному общему шаблону "поездки на такси".

Но каждая конкретная поездка — это экземпляр этого процесса:

Представьте, что вы хотите приготовить суп. Сам процесс "приготовление супа" кажется большим и сложным, но если разбить его на более мелкие шаги, он становится намного понятнее и выполнимее:

Декомпозиция процессов — это как приготовление обеда.

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

Большой процесс (например, "обработка заказа клиента") разбивается на более мелкие этапы:

Так же работает декомпозиция процессов в бизнесе и IT :

Декомпозиция процессов — это как разделение большой задачи на маленькие, последовательные шаги, чтобы было проще понять и выполнить.

Проще говоря:

приём заказа;

проверка наличия товара;

оплата;

упаковка;

доставка.

покупка ингредиентов;

подготовка продуктов (помыть, почистить, нарезать);

вскипятить воду;

добавить ингредиенты в кастрюлю;

варить определённое время;

подавать готовый суп на стол.

Представьте, что вы заказали еду в ресторане. Ваш заказ проходит через несколько четко определенных стадий (статусов), пока не будет готов:

Это набор состояний (статусов), через которые проходит объект (например, задача, заявка или документ) в системе.

Статусная модель в IT — это как стадии готовки блюда на кухне.

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

Например, в системе управления проектами задача может иметь такие статусы:

Так же работает статусная модель в IT :

Статусная модель — это как этапы жизни объекта, которые показывают, где он находится и что с ним происходит, как стадии готовки блюда в ресторане.

Проще говоря:

Новая — задача только создана.

В работе — кто-то уже занимается её выполнением.

На проверке — задача выполнена, но её проверяют.

Завершена — задача полностью готова.

Принят — официант записал ваш заказ;

В обработке — повар начал готовить;

Готовится доставка — блюдо упаковано и передано курьеру;

Доставлено — курьер привез заказ, и вы его получили.

Это "кухня" системы, которая скрыта от глаз пользователя.

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

Пользователь не видит backend напрямую, но именно он обеспечивает работу всего сервиса.

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

Backend — это как кухня в ресторане.

Так же работает backend в IT :

Backend — это всё, что происходит "за кулисами", как кухня в ресторане: вы не видите её, но она готовит то, что вы получаете на выходе.

Проще говоря:

Это всё, что пользователь видит и с чем может взаимодействовать напрямую: кнопки, меню, тексты, изображения, формы для ввода данных.

Frontend отвечает за то, чтобы интерфейс был понятным, удобным и красивым, как витрина магазина.

Но сама витрина ничего не делает без "кухни" (backend): она просто показывает данные и отправляет ваши действия дальше.

Представьте, что вы идёте в магазин и видите красивую витрину. На ней всё аккуратно расставлено, подписано, есть кнопки или интерактивные элементы (если это современный магазин), чтобы вам было удобно выбирать товары. Вы взаимодействуете только с тем, что видите спереди: трогаете товары, читаете ценники, нажимаете на кнопки или выбираете что-то через экран.

Frontend — это как витрина магазина.

Так же работает frontend в IT :

Frontend — это всё, что вы видите и с чем можете "поиграться", как витрина магазина: красиво, удобно и понятно, но это только внешняя часть системы.

Проще говоря:

Библиотекарь — это API:

API (Application Programming Interface) — это посредник, который помогает клиенту (вам) и серверу (склад книг) взаимодействовать.

Когда вы говорите библиотекарю: "Хочу книгу про космос", вы формулируете запрос в понятной для него форме (например, называете тему или автора). Это похоже на то, как клиент отправляет запрос через API.

Библиотекарь "переводит" ваш запрос в действие: идет на склад, находит нужную книгу и возвращает её вам. То есть он обеспечивает связь между вами и складом, так же как API обеспечивает связь между клиентом и сервером.

Представьте, что вы хотите взять книгу в библиотеке:

Клиент-серверная архитектура — это как работа с библиотекой.

Библиотекарь приносит вам книгу, и вы получаете результат.

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

Клиент (например, ваш компьютер) отправляет запрос серверу ("хочу эти данные").

Сервер находит нужную информацию и отправляет её обратно.

Клиент показывает вам результат.

Так же работает клиент-серверная архитектура :

Клиент-серверная архитектура — это как работа с библиотекой: клиент делает запрос, сервер находит нужное и возвращает ответ.

Проще говоря:

Вы — это клиент . Вы подходите к библиотекарю и говорите: "Хочу книгу про космос".

Библиотекарь — это связующее звено, который передает ваш запрос дальше.

Склад книг (фонд) — это сервер . Там хранятся все книги, и оттуда берут именно ту, которую вы попросили.

Монолитная архитектура — это как небольшой семейный магазин.

Монолитная и микросервисная архитектура

Представьте, что у вас есть маленький магазин, где работает один продавец (или семья). Этот человек делает всё: принимает заказы, собирает товары, рассчитывает покупателей, убирает помещение и даже чинит полки. Всё в одном месте, и всё зависит от одного человека.

Если этот человек заболеет, магазин закрывается.

Если нужно внедрить новую систему учета товаров, придется обучать именно этого человека, и он будет долго перестраиваться.

Система разделена на множество независимых сервисов (как отделы в супермаркете).

Каждый сервис выполняет свою задачу (например, авторизация, оплата, каталог товаров).

Если один сервис выходит из строя, остальные продолжают работать.

Легче масштабировать (можно добавить больше сотрудников на кассу, если очередь длинная).

Так же работает микросервисная архитектура :

Это одна большая система, где все компоненты тесно связаны между собой.

Простота в начале (один магазин, один продавец), но сложность с масштабированием и изменениями.

Если что-то ломается, может "упасть" вся система.

Так же работает монолитная архитектура :

Если кто-то из сотрудников заболеет, остальные продолжат работать. Если нужно обновить систему на кассах, это не повлияет на работу склада или других отделов. Каждый отдел работает независимо, но вместе они обеспечивают работу всего магазина.

Один сотрудник на кассе;

Другой раскладывает товары на полках.

Третий следит за складом.

Четвертый помогает покупателям с выбором.

Монолитная архитектура — это как один универсальный инструмент, который решает все задачи.

Микросервисная архитектура — это как набор специализированных инструментов, каждый для своей задачи

Итог:

Монолитная архитектура : Один человек делает всё в маленьком магазине. Просто, но сложно менять и развивать.

Микросервисная архитектура : Большой супермаркет с разными отделами и сотрудниками. Гибко, независимо, но требует больше координации.

Простое сравнение:

Микросервисная архитектура — это как большой супермаркет.

Теперь представьте огромный супермаркет, где работает много сотрудников, и каждый занимается своим делом:

Синхронные запросы — это как заказ в кафе с ожиданием у стойки.

Синхронные и асинхронные запросы

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

Клиент отправляет запрос серверу: "Дай мне данные".

Сервер говорит: "Хорошо, я обработаю это, а ты пока можешь заниматься своими делами".

Когда данные готовы, сервер отправляет ответ (например, через уведомление), и клиент продолжает работу с результатом.

Так же работает асинхронный запрос :

Синхронные запросы — это "запросил и ждёшь".

Асинхронные запросы — это "запросил, отвлекся, получил уведомление"

Итог:

Синхронные запросы : Стоите у стойки и ждёте. Ничего другого не делаете.

Асинхронные запросы : Заказали кофе, ушли гулять, а потом вернулись за ним.

Простое сравнение:

Асинхронные запросы — это когда вы отправляете запрос и можете заниматься другими делами, пока ждёте ответ, как если бы вы заказали кофе и пошли прогуляться.

Проще говоря:

Синхронные запросы — это когда вы ждёте ответа, ничего больше не делая, как если бы вы стояли у стойки и ждали свой кофе.

Проще говоря:

Клиент отправляет запрос серверу: "Дай мне данные".

Сервер обрабатывает запрос, и клиент просто ждёт, пока придёт ответ.

Всё "останавливается" для клиента до получения результата.

Так же работает синхронный запрос :

Асинхронные запросы — это как заказ в кафе с возможностью прогуляться.

Теперь представьте, что вы приходите в кафе, делаете заказ: "Хочу кофе", но вместо того чтобы ждать у стойки, вы говорите: "Когда кофе будет готов, позвоните мне или отправьте уведомление". Пока кофе готовится, вы можете погулять, почитать книгу или сделать что-то ещё. Когда кофе готов, вам сообщают, и вы забираете его.

DELETE — это как выбрасывание письма из ящика.

PUT — это как замена старого письма на новое.

Теперь представьте, что вы решили избавиться от ненужного письма. Вы берёте его из почтового ящика и выбрасываете в мусор.

Представьте, что вы нашли ошибку в уже отправленном письме, вернулись к своему почтовому ящику и заменили старое письмо на исправленное. Если письма не было, вы можете положить его туда, но если оно уже есть — вы его обновляете.

Так же работает DELETE :

Это запрос на удаление данных с сервера (например, удалить комментарий, запись или файл).

Так же работает PUT :

Это запрос на обновление или замену существующих данных на сервере (например, изменить текст статьи или обновить профиль пользователя).

DELETE — это "удалить что-то".

Проще говоря:

PUT — это "обновить или заменить".

Проще говоря:

POST — это как отправка нового письма.

Теперь представьте, что вы пишете новое письмо и кладёте его в почтовый ящик для отправки. Вы создаёте что-то новое, что другие смогут получить или обработать.

GET — это как проверка почтового ящика.

Представьте, что вы подходите к своему почтовому ящику и заглядываете внутрь, чтобы посмотреть, какие письма пришли. Вы ничего не меняете, просто читаете или просматриваете содержимое.

Так же работает POST :

Это запрос на создание новых данных на сервере (например, добавить новую запись, отправить комментарий или загрузить файл).

POST — это "добавить что-то новое".

Проще говоря:

GET — получить данные.

POST — создать новые данные.

PUT — обновить или заменить данные.

DELETE — удалить данные.

Как будто вы управляете своим почтовым ящиком!

Итог:

GET : Посмотреть, что есть в почтовом ящике.

POST : Добавить новое письмо.

PUT : Обновить или заменить старое письмо.

DELETE : Выбросить письмо.

Простое сравнение:

Так же работает GET :

Это запрос на получение данных с сервера (например, список писем, новостей или товаров).

Вы только запрашиваете информацию, ничего не добавляя и не изменяя.

GET — это "посмотреть, что есть".

Проще говоря:

PATCH — это как ремонт конкретной детали телефона.

Теперь представьте, что ваш телефон сломался, но вы решили починить только разбитый экран. Вы не меняете весь телефон, а ремонтируете только ту часть, которая нуждается в исправлении.

PUT — это как полная замена телефона на новый.

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

Так же работает PATCH :

Это запрос на частичное обновление ресурса (данных) на сервере.

Вы отправляете только те изменения, которые нужно внести, без необходимости передавать всю информацию заново.

PATCH — это "починить только то, что сломано".

Проще говоря:

PUT — это полная замена данных (весь объект).

PATCH — это частичное обновление данных (только нужные поля).

Как будто вы решаете, ремонтировать ли только сломанную часть или заменить всё сразу!

Итог:

PUT : Купили новый телефон целиком, даже если проблема была только в экране.

PATCH : Починили только экран, оставив остальное без изменений.

Простое сравнение:

Так же работает PUT :

Это запрос на полное обновление ресурса (данных) на сервере.

Даже если нужно изменить только одну часть данных, вы отправляете всю информацию заново.

Если ресурс уже существует, он полностью перезаписывается. Если его нет, он создаётся.

PUT — это "заменить всё целиком".

Проще говоря:

API — это как меню в ресторане.

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

Так же работает API :

Это "меню" для программ: список доступных команд (блюд) с описанием того, что они делают.

Вы (ваша программа) выбираете нужную команду (заказываете блюдо), отправляете запрос через API (официант передает заказ), и сервер выполняет задачу (повар готовит блюдо), после чего вы получаете результат.

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

Проще говоря:

Это как курьерская служба или почтовое отделение.

Представьте, что вы хотите отправить письмо другу, но не знаете, как оно дойдёт до адресата: возможно, он живёт в другом городе, или у него нет времени сразу его получить. Вы отдаёте письмо в почтовое отделение, а они уже доставляют его адресату, независимо от того, где он находится и когда сможет его забрать.

Так же работает брокер сообщений :

Он получает данные (письма) от одного сервиса и доставляет их другому, даже если второй сервис временно недоступен или работает с другой скоростью.

Это надёжный посредник, который гарантирует, что информация дойдёт до цели.

Событийная архитектура — это как система оповещений в аэропорту.

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

Так же работает событийная архитектура :

Когда происходит важное событие — например, ваш рейс объявлен посадочным или задержан — система автоматически отправляет вам уведомление. При этом разные службы аэропорта (регистрация, багаж, авиакомпании) работают независимо, но все они могут "выстреливать" события, которые важны для пассажиров или других служб.

Система состоит из множества независимых компонентов (служб), которые общаются через события.

Когда что-то важное происходит (например, пользователь нажал кнопку, данные обновились или задача выполнена), компонент генерирует событие.

Другие компоненты, которые "подписаны" на такие события, получают уведомление и реагируют на него.

Событийная архитектура — это как система уведомлений, где каждый участник знает только то, что ему нужно, и реагирует только на те события, которые его касаются

Проще говоря:

БД и СУБД — это как библиотека с библиотекарем.

Представьте, что у вас есть огромное количество книг (данных), и вам нужно их хранить, организовывать и быстро находить нужную книгу (информацию) по запросу.

Так же работает СУБД :

Вы могли бы просто свалить все книги в кучу, но тогда поиск займёт много времени. Вместо этого вы организуете их на полках (таблицах), расставляете по категориям (структурам) и нанимаете библиотекаря (СУБД), который знает, где что лежит, и может быстро достать нужную книгу или записать новую.

Она хранит данные в упорядоченном виде, позволяет быстро добавлять, изменять, искать и удалять информацию, а также следит за тем, чтобы всё работало чётко и без ошибок.

Представьте, что вы идёте в магазин и хотите взять с собой список того, что нужно купить. Чтобы не запутаться, вы пишете его в удобной форме: указываете категории (например, "фрукты", "овощи") и перечисляете товары с их количеством:

Так же работает JSON :

Это простой способ записать информацию в виде текста, который легко читать и человеку, и компьютеру.

Данные организованы в пары "ключ: значение" (как "морковь: 5") или списки (как "фрукты").

JSON используется для обмена информацией между программами, как ваш список помогает вам ориентироваться в магазине.

JSON — это универсальный формат для хранения и передачи данных, похожий на структурированный список.

Проще говоря:

API Gateway — это как консьерж в элитном жилом комплексе.

Представьте, что вы хотите попасть в одну из квартир комплекса, но у вас нет прямого доступа к каждой двери.

Так же работает API Gateway :

Вместо этого вы обращаетесь к консьержу, который знает всех жильцов и может связаться с нужной квартирой за вас. Он проверяет вашу личность, передает ваш запрос (например, "я хочу встретиться с жильцом квартиры 15"), а затем проводит вас к нужной двери или даже доставляет ответ от жильца.

Это посредник между клиентом (вами) и множеством сервисов (квартир).

Он принимает все входящие запросы, проверяет их (аутентификация, авторизация), определяет, к какому сервису нужно обратиться, и направляет запрос туда.

Также он может объединять ответы от нескольких сервисов в один удобный ответ для клиента.

API Gateway — это единая точка входа, которая управляет всеми запросами, защищает внутренние сервисы и делает взаимодействие удобным и безопасным.

Проще говоря:

Представьте, что вы снимаете короткий фильм. Чтобы все знали, кто и когда что делает, вы заранее рисуете раскадровку: кто говорит первую реплику, кто отвечает, какие действия происходят и в каком порядке. Например:

Sequence Diagram (Диаграмма последовательности) — это как раскадровка к фильму.

Она показывает, кто (например, пользователь, сервер или база данных) и в какой последовательности обменивается сообщениями или выполняет действия.

Каждый "участник" изображён как отдельный столбец, а стрелки между ними показывают, как идёт взаимодействие.

Так же работает Sequence Diagram :

Sequence Diagram — это раскадровка для программистов, которая наглядно демонстрирует, кто, как и в каком порядке взаимодействует в системе.

Проще говоря:

Актёр 1 говорит: "Привет!"

Актёр 2 отвечает: "Привет! Как дела?"

Актёр 1 достаёт телефон и показывает фото.

Актёр 2 улыбается и кивает.

Представьте, что вы выбираете машину. Вы знаете, что она должна ездить (это функциональное требование). Но вас также интересуют такие вещи:

Нефункциональные требования — это как характеристики автомобиля, которые не говорят, что он делает, но определяют, насколько хорошо он это делает.

Они описывают, как система должна работать, а не что она должна делать.

Например, насколько быстро приложение отвечает на запросы, сколько пользователей оно может обслуживать одновременно, насколько безопасно и удобно оно для пользователей.

Так же работает нефункциональные требования в IT :

Нефункциональные требования — это "качество" системы: они определяют, насколько хорошо она выполняет свою задачу.

Проще говоря:

Насколько быстро она разгоняется? (производительность)

Сколько она потребляет топлива? (эффективность)

Удобно ли в ней сидеть? (удобство использования)

Насколько надёжна её конструкция? (надёжность)

Можно ли легко найти запчасти? (поддерживаемость)