4. Области интересов, системные уровни и цепочки создания
4.4. Платформенный стек проекта
Приведите пример платформенного стека в вашем рабочем проекте (не меньше трёх уровней).
По необходимости формируйте заметки при повторном заполнении таблицц-шаблонов. Можете записать рефлексию и результат проведенной работы над ошибками.
Уровни стека
0
Пример: стек ШСМ
Ваш пример
Заметки
Пример: стек ШСМ
Ваш пример
Заметки
1
Фронт: vue.js, bootstrap, scss, Vaadin (старый фреймворк, переходим с него)
2
Почтовые рассылки: Mailjet - массовые рассылки (пока ручные, в процессе - автоматизированные), SMTP Beget - транзакционные письма
3
Бэк: Java Virtual Machine on Tomcat 9. С использованием Spring с Hibernate для ORM и сохранения/чтения данных, Integromat (связь сайта и CRM в Aisystant)
Платформа — это всегда продуктное/конструктивное/модульное рассмотрение системы с подчёркиванием стандартности получения требуемого от модуля сервиса через опубликованный интерфейс. Обсуждение платформы всегда связано с её сервисами, т.е. внешним поведением, предоставляемом на интерфейсе к вышестоящим в продуктном/конструктивном/модульном разбиении более крупным продуктам/модулям.
Основной вопрос при обсуждении платформ — это так называемая видимость интерфейсов. Интерфейсы какого-то низкого системного уровня не должны быть видны снаружи модуля, то есть нельзя соединять модули иначе, чем через предусмотренные в нём интерфейсы.
Главное в рассмотрении технологического стека то, что никакой модуль/продукт вышестоящего уровня «не видит» модули более низкого уровня (не имеет к ним доступа, не может туда «воткнуться»), чем находящийся непосредственно под ним, и интерфейсы реализующих сервисы этих платформенных уровней стандартизованы — как стандартизован и сам набор этих уровней.
Платформенность даёт возможность эффективного разделения труда: реализацией каждого уровня платформенного стека может заниматься отдельная команда, хорошо разбирающаяся в работе на их системном уровне, а поскольку речь идёт о модулях, реализующих/исполняющих роль функциональных частей, то такие команды могут соревноваться за эффективность реализации требуемых функций сервисами своих модулей — на каждом системном уровне своих.
Инженеры, использующие какие-то платформы для создания своих целевых систем, могут не задумываться, как именно и из каких систем были сделаны сами эти платформы. Инженеры могут использовать прикладной интерфейс платформ, не интересуясь устройством этих платформ — лишь бы эти платформы осуществляли сервис, осуществляя его через описанный интерфейс. Это существенно упрощает задачу создания сложных систем, ускоряет и удешевляет её. Нужно хорошо разбираться в вариантах модулей и выдаваемых ими на их интерфейсах сервисах, но необязательно разбираться, как они устроены внутри, и как именно они внутри себя работают.
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
