Любая программа состоит из 3ех фундаментальных частей:
— Ввод
— Обработка
— Вывод
И данная абстракция над любой программой поможет нам разобраться с одним из первых, как мне кажется, архитектурным подходом, который зародился вместе с современными языками программирования.
И идея его проистекает из способа работы с железом:
🔹 У нас есть спецификация платы, чипа
🔹 У каждого чипа, платы есть порты
🔹 Каждый порт соответствует пину, ножке чипа
🔹 Проставив значение hot (1) на один из пинов/ножек, мы просим чип выполнять какие-либо операции
🔹 Вывод этих операций мы можем "слушать" с другого порта согласно спецификации
Так мы можем складывать числа, включать/выключать диод на плате, загружать операционную систему.
Для наглядности можно посмотреть это видео с канала Low Level Learning.
И любая работа с железом всегда строилась таким образом:
🔸 Ты пишешь по магическому адресу магическое число (ввод)
🔸 Получаешь по магическому адресу магический ответ (вывод)
Дааа, embedded программирование — чистая магия, не иначе 🤣
А теперь абстрагируемся:
🔹 Любой способ получить данные — ввод
🔹 Любой способ вывести/сохранить данные — вывод
🔹 Преобразование ввода в вывод — сама суть любой программы 🫡
Но мы ведь не работаем с чистыми битами и регистрами, мы просто пишем
File.Read, WebRequest.Process и получаем данные в удобном формате.А раньше работали и каждый по своему мог организовывать ввод и вывод.
Именно из-за особенности связи код-железо и появился архитектурный подход "Порты и Адаптеры".
Суть:
🔸 Порт — это любая абстрактная сущность, которая предоставляет данные.
Мы ее "слушаем" и получаем/отправляем данные
🔸 Адаптер — конвертер/преобразователь в формат представления структур/объектов языка.
Т.е. это простейшее разбиение на 2 операции:
🔹 Отправка/получение данных
🔹 Десериализация (а по факту демаршалинг) данных
Оно и дает нам один из первых (лично я ничего более раннего не нашел) архитектурных подходов.
Программа слушает несколько портов, агрегирует данные, отдает их в сыром виде в адаптер, который уже отдает понятную структуру для работы.
🔻Это позволяет нам в целом абстрагироваться от способа получения данных и реализовать поддержку бесконечного кол-ва источников.
В том числе мы можем сделать fake источник, тем самым делая возможным тестирование логики.
Этот подход позже был экстраполирован на крупные системы и был переименован в Hexagonal architecture.
Где каждая грань многогранника обозначала свою связку порта и адаптера.
Ремарка:
Название "Порты и Адаптеры (Ports and Adapters)" это второе название Hexagonal Architecture, которая решает проблемы совсем другого уровня.
У меня же в статье "Порты и Адаптеры" никак не связаны с Hexagonal Architecture. Я рассматриваю этот подход отдельно и независимо.
Я позволяю себе такое, потому что следы "Портов и Адаптеров" можно найти задолго до Hexagonal Architecture, например в документации к Apple Macintosh 1992 года 👍
В играх реализацию данного подхода можно встретить при низком уровне работы с данными.
Когда мы гоняем байты по сети через сокет и нам нужно быстро их преобразовать в объекты языка для дальнейшей работы с ними.
Вот пример адаптера с проекта Magic Battle Arena.
Реализацией порта в этом случае был класс TcpServer.
Сохраняй себе, чтобы не потерять и делись с коллегами 📞
Ставь 👍 если тебе заходит такого рода контент!
#архитектурные_подходы@UniArchitect
