Универсальный Backend for Frontend для всех платформ RUTUBE

У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя. А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.

https://habr.com/ru/companies/habr_rutube/articles/970690/

#bff #nestjs #nodejs #архитектура_приложений #рефакторинг #fastify #redis #backend #frontend #видеосервисы

Как мы создавали курс «Архитектура программного обеспечения» — и как прошёл рефакторинг программы

Почти каждый разработчик рано или поздно сталкивается с задачей, когда ему нужно спроектировать такое сложное изменение в системе, которое затронет сразу несколько продуктов или команд. Кроме того, понимание архитектуры программного обеспечения ценится на рынке — ведущие IT-компании стремятся сохранять прежде всего тех, кто понимает, как устроены системы и решения, и способен решать сложные инженерные задачи. На связи команда курса «Архитектура программного обеспечения» в Яндекс Практикуме. В этом материале мы расскажем, как ответили на запрос рынка и разработчиков и стали готовить инженеров в области архитектуры ПО, а также какие изменения внесли в курс совсем недавно.

https://habr.com/ru/companies/yandex_praktikum/articles/965762/

#архитектура_по #архитектура_приложений

Под капотом современных AI-систем: разбираем железо

Как объединить по сети вычислители? Что происходит при компиляции кода для железа под капотом и какие есть нюансы при работе с AI в пространстве ядра? ИИ с ноги ворвался во все сферы разработки, работы — вагон и маленькая тележка. Но на чём и как она должна ехать? У каждой программы есть свои требования, универсальных советов нет. О новых решениях можно будет узнать на конференции

https://habr.com/ru/companies/oleg-bunin/articles/968426/

#разработка #конференция #ии #ai #компиляторы #rust #tensorrt #нейросети #архитектура #архитектура_приложений

Снижаем когнитивную сложность при проектировании архитектуры приложения

Когнитивная сложность - это понятие, описывающее сложность процесса познания и мышления. Оно используется в разных областях: в психологии оно характеризует индивидуальную способность к восприятию и обработке информации. Более высокая когнитивная сложность означает, что система (будь то человек или программа) требует больше усилий для понимания и может быть трудной в поддержке. Когнитивная сложность при проектировании приложения часто возникает из-за смешения архитектуры кода и архитектуры приложения. В большинстве случаев эти термина никак не разделены, а также эти термины не имеют однозначного толкования, как по содержанию так и по контексту использования. В практике и литературе эти понятия часто используются как синонимы или в пересекающихся контекстах, что приводит к неоднозначности. В зависимости от контекста (например, обсуждение микросервисов, монолитов, паттернов проектирования или рефакторинга), один и тот же термин может обозначать как уровень организации кода, так и более высокий уровень организации приложения или системы. В профессиональной литературе и стандартах (например, TOGAF, ArchiMate) архитектура программного обеспечения охватывает оба аспекта и организацию кода, и организацию приложения, что еще больше стирает границы между этими понятиями. Пора этой порочной практике сказать решительное НЕТ! Сказать решительное НЕТ

https://habr.com/ru/articles/968170/

#архитектура_приложений #system_design

Архитектура ИТ решений. Часть 6. Подходы к построению Архитектуры

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

https://habr.com/ru/articles/967520/

#архитектура_приложений #архитектура_по #архитектура_систем #слои_архитектуры #итинфраструктура #итиндустрия #моделирование_решений #моделирование_предметной_области #предприятие #структура_компании

Архитектура фронтенда. Навеяно болью от использования FSD

Кто я такой и с какой горы прибыл? Зовут меня Юра и у меня немногим больше семи лет опыта разработки фронта на vue+typescript. Начал я, что забавно, с Angular 5 в далёком 2018, когда пятёрка ещё была актуальной версией, и работал с ним немногим больше пары месяцев, после чего перекатился во vue2. Работал я исключительно в B2B и внутренней разработке. Системы документооборота, сервисдески и вот это вот всё. Благодаря этому я повидал разного. От DDD, до "паста-болоньезе-код". На последних двух проектах я наступил в FSD. Методологию для организации кодовой базы выбирал не я, но я честно пытался в ней разобраться и как-то удобно организовать. К сожалению, оба раза код становился проблемой с высокой связностью, неочевидным размещением сущностей и сложно отслеживаемой системой взаимодействий компонентов кода. При всём этом я наблюдал активный рост популярности FSD методологии в сообществе. Это натолкнуло меня на мысль о том, что я просто недостаточно разобрался, и тогда я начал копать. Смотреть, как же готовят FSD, сравнивать с известными мне архитектурными подходами. В этой статье я хочу поделиться выводами, к которым пришёл, и предложить решения, которые нашёл.

https://habr.com/ru/articles/966962/

#мнение #frontend #архитектура_приложений #fsd

Как пройти секцию по System Design на Senior: не проектируй системы — проектируй компромиссы

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

https://habr.com/ru/companies/otus/articles/965618/

#system_design #Архитектура_приложений #архитектура #проектирование_систем #масштабирование #собеседование #инженерное_мышление #отказоустойчивость #highload

[Перевод] Всё, что я знаю о хорошем системном дизайне

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

https://habr.com/ru/companies/otus/articles/960948/

#system_design #system_architecture #системный_дизайн #архитектура_приложений #распределённые_системы #масштабируемость #надежность #базы_данных #проектирование_сервисов

Архитектура ИТ решений. Часть 4. Архитектура приложений. 4.2. Портфель прикладных систем

Портфель прикладных систем (Application Portfolio) - это ключевое понятие в управлении ИТ-архитектурой, описывает потребности бизнес-процессов предприятия в информационных технологиях, которые способны обеспечить автоматизированное ведение деятельности. Включает в себя набор интегрированных информационных систем. Как существующих, так и вакантных на данный момент, то есть тех, которые потребуются в будущем для обеспечения новых потребностей бизнеса и деятельности организации. Таким образом он позволяет определить актуальный уровень покрытия необходимой функциональности бизнес-архитектуры, цифровыми решениями. А также устанавливает ответственность и приоритетность каждого приложения и варианты достижения результата, посредством либо разработки системы, либо приобретения готовых приложений, учитывая интеграцию и использование возможностей уже имеющихся ИС. Рассмотрим эффект применения этого инструмента с разных ракурсов. С точки зрения установления актуального состояния архитектуры, портфель описывает текущее положение компенсированности бизнес процессов предприятия - цифровыми решениями. С точки зрения стратегии развития архитектуры, портфель презентует набор целевых прикладных систем, которые должны в перспективе удовлетворять потребности бизнес-процессов предприятия. С точки же зрения процесса реализации планов развития, под портфелем понимается совокупность проектов, выполняемых на общем пуле ресурсов предприятия (финансы, люди, оборудование, материалы, энергия и прочее), направленных на трансформацию бизнес-процессов организации путем внедрения их цифровых двойников.

https://habr.com/ru/articles/961910/

#архитектура_приложений #архитектура #архитектура_по #архитектура_систем #слои_архитектуры #уровни_зрелости #итинфраструктура #портфель_проектов #портфельные_инвестиции

conway-errors: порядок в ошибках как часть архитектуры проекта

Однажды при работе с крупной кодовой базой одного фронтенд-приложения я заметил, что функционал постепенно группируется относительно команд (доменов). Каждая из таких групп функционала постепенно накладывает собственные ограничения на архитектуру. Как оказалось, обработка ошибок при сравнении кода двух разных команд неоднородна. В одном случае разработчики структурировали ошибки стандартным наследованием JS/TS, в другом были использованы перехваты возникающих ошибок и логирование. Стало ясно, что нам требуется обобщить подход к тому, как мы структурируем (называем, наследуем) и выбрасываем ошибки. Как показала практика, соглашений о кодировании недостаточно. Что мы хотели получить?

https://habr.com/ru/articles/961184/

#ошибки #ошибки_в_коде #обработка_ошибок #архитектура_приложений #фронтенд #бэкенд

Архитектура ИТ решений. Часть 4. Архитектура приложений. 4.1. Область разработки прикладных систем

В предыдущей части мы обсудили общие аспекты ИТ Архитектуры, и подробно затронули такой ее слой, как архитектура Данных, которая охватывает все многообразие бизнес-информации предприятия, знания о потоках ее распределения, сборе, обработке и использовании, представляемой в виде различных моделей данных. Теперь обратимся к слою Приложений, который соотнесет используемые данные и правила их обработки с компьютерными программами, для их хранения, получения и преобразования в ходе автоматизированного выполнения бизнес-процессов. Архитектура прикладных решений (ESA –Enterprise Solution Architecture) — это организационный дизайн всего программного приложения, включая все подкомпоненты и внешние приложения, интерфейсы для их взаимодействия, а также их поведения в рамках сотрудничества структурных элементов. Используются этот инструмент для описания модели того, как приложение будет обеспечивать жизненный цикл необходимых бизнес-процессов, соответствующих бизнес-архитектуре предприятия. Архитектура приложений покрывает достаточно широкую область, начиная с идентификации прикладных систем необходимых предприятию для выполнения бизнес-процессов, и захватывает такие аспекты, как проектирование, разработку (или приобретение) и интеграцию прикладных систем в комплексные решения. Потому для упрощения восприятия, как правило, разделяют две основные области ее применимости:

https://habr.com/ru/articles/960984/

#архитектура_приложений #архитектура_по #архитектура_системы #слои_архитектуры #архитектурные_паттерны #итинфраструктура #итиндустрия #принципы_проектирования #приложения #паттерны_проектирования

Чек-лист, который превращает интеграцию из хаоса в процесс

Добрый день, дорогие читатели! Хотела бы поделиться своим накопленным опытом и предложить вам некий универсальный чек-лист или даже в некоторой степени перечень рекомендаций в разрезе активностей и ролей, который поможет вам при интеграции систем, подготовке новых проектов. Желаю вам приятного чтения!

https://habr.com/ru/articles/960234/

#интеграция #интеграция_сервисов #интеграция_систем #интеграция_приложений #интеграция_данных #проектирование_систем #system_design #архитектура #архитектура_приложений #архитектурные_паттерны

Архитектура ИТ решений. Часть 3. Информационная архитектура

В предыдущих частях курса мы погрузились в масштабность общего восприятия архитектуры в рамках предприятия. Прошли слой Бизнес-архитектуры, рассуждая о работе организаций в терминах бизнес-моделей, бизнес-процессов, потоков ценностей и способностей бизнеса, организационной структуры и прочего. Эти знания уже сами по себе чрезвычайно важны, для организации максимально эффективного функционирования предприятия, даже без учета ИТ составляющей. Но поскольку основная цель нашего курса — это все же развитие ИТ технологий, то с этой позиции представление Бизнес-архитектуры, служит отправной точкой на пути создания ИТ решений, которым предопределено поддерживать и развивать деловые активности предприятия. Так шаг за шагом, мы поднялись на горизонт ИТ-архитектуры. Перед тем как приступить к рассмотрению Слоя информации , давайте все же кратко еще раз остановимся на рассмотрении общего восприятия аспектов ИТ-архитектуры. ИТ-архитектура предприятия (Enterprise IT Architecture) — это системное представление структуры, компонентов и взаимодействий всех информационных технологий , которые поддерживают бизнес-процессы, ценности и стратегию организации. Иными словами — это “скелет” технологической среды , который обеспечивает реализацию бизнес-архитектуры и поддержку бизнес-способностей . Из определения следует, что ИТ-архитектура , является неразделимой частью Архитектуры предприятия , всецело зависит от той мисси, которую в данной организации предопределили для информационных систем. В связи с этим она может фокусироваться на разных подходах к решению и быть:

https://habr.com/ru/articles/958942/

#архитектура_приложений #архитектура #архитектура_по #архитектура_системы #слои_архитектуры #уровни_зрелости #архитектурные_паттерны #итинфраструктура #итиндустрия

Архитектура ИТ решений. Часть 2. Бизнес-архитектура

Продолжаем рассматривать вопросы, связанные с проработкой архитектурных решений в области цифровизации предприятий. Сталкивались ли Вы с ситуацией, когда ИТ проект, в котором задействована сильная команда разработчиков, в конечном счете выпускает программный продукт, не удовлетворяющий потребностям бизнеса? Когда полученный вариант попросту никак не облегчает жизнь компании, не избавляет от ее болей и печалей, не переводит ее процессы на качественно новый уровень. Чаще всего такой итог означает, что затеявшие цифровую трансформацию специалисты, не справились со своей основной задачей и просчитались, скорее всего, еще на этапе анализа. А причина тому - отсутствие экспертизы в области архитектуры бизнеса. И аргумент: «как нам заказчик объяснил, так мы и сделали», служит слабым оправданием. Команда профи, должна была, обследовав предприятие, указать на нелогичность цепочек бизнес-процессов, нерелевантность используемых бизнес-сервисов, избыточность организационной структуры, искажения потоков ценностей и прочие упущения, присущие первоначально сложившейся архитектуре. Квалифицированный специалист в области организации бизнеса должен гарантировать качественный инжиниринг и реинжиниринг деятельности предприятия, используя при этом профессиональные подходы, инструменты и приемы. Результат этих активностей и должен заложить основу для последующей эффективной цифровизации деятельности заказчика. В данном аспекте важно учитывать, что на больших предприятиях цифровизацией будут заниматься множество команд, использующих разные технологические платформы, методологии, и накопленный ранее приватный опыт автоматизации. Их технические новации в свою очередь будут влиять на выстраивание бизнес-решений, определяя то, как бизнес будет меняться и развиваться. А потому, если централизовано не управлять слоем бизнес-архитектуры, то разнообразные ИТ-технологии могут привести к культивированию зоопарка управленческих, финансовых, предпринимательских и прочих бизнес-решений в общей структуре предприятия, вызывая противоречия, неконструктивную конкуренцию, затруднение в управлении и прочие кризисные предпосылки.

https://habr.com/ru/articles/956656/

#архитектура #архитектура_приложений #архитектура_системы #слои_архитектуры #уровни_зрелости #информационная_архитектура #архитектурные_паттерны #архитектура_по #итинфраструктура #итиндустрия

Архитектура ИТ решений. Часть 1. Понятие «Архитектура»

Данный курс является продолжением образовательной программы в области проектирования Информационных систем (далее ИС). В рамках этой части - «Архитектура ИТ решений», мы с Вами рассмотрим вопросы проектирования и организации, применительно к большим глобализационным системам. Часто, когда отдельные ИТ-системы, по мере развития цифровизации начинают объединять в более крупные, всеобъемлющие решения, команды сталкиваются с проблемами восприятия:

https://habr.com/ru/articles/955218/

#архитектура #архитектура_приложений #архитектура_систем #слои_архитектуры #уровни_зрелости #информационная_архитектура #архитектурные_паттерны #архитектура_по #итинфраструктура

Function Object — как основа бизнес логики приложения

В предыдущей статье " Адаптированный паттерн Command с использованием Dependency Injection ", я описывал как инкапсуляция логики приложений в отдельные объекты-функции позволяет получить преимущества в архитектуре приложений. В качестве основы для концепции объекта-функции мной был выбран известный паттерн Command, но обсуждение статьи показало, что читателям тяжело отказатся от слишком узкой специфики паттерна Command и это мешяет восприятию материала. Эта статья пытается исправиль допущенную автором ошибку. Статья является дополнением к предыдущей.

https://habr.com/ru/articles/954516/

#function_object #архитектура_приложений

Мой опыт over-engineering: как 4 микросервиса на Spring Boot убили pet-проект

История о том, как попытка построить «идеальную» архитектуру для простой задачи обернулась системой из 4 сервисов, потребляющей 8 ГБ ОЗУ и 15 ГБ диска. Разбираю свои ошибки и выводы, которые помогут не повторять их другим разработчикам.

https://habr.com/ru/articles/950768/

#java #spring #микросервисы #архитектура_приложений #ошибки_проектирования

PCI DSS глазами архитектора: разбираем кейс передачи карточных данных в ДБО

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

https://habr.com/ru/companies/otpbank/articles/944970/

#финтех #финтехпроекты #pcidss #интеграции #интеграции_сервисов #отп_банк #архитектура #архитектура_приложений #информационная_безопасность

Микросервисы vs Монолиты: что на самом деле ускоряет разработку

Привет, Хабр! Поскольку первая встреча прошла очень полезно и интересно, мы решили повторить и снова в эфире телеграм-канала Dev Q&A продолжили дискуссию о микросервисах и скорости разработки. Собрались технические эксперты из BPMSoft, DevTale, Revizto и Диасофт (в лице меня). Обменялись практическими примерами на тему как же упростить жизнь разработчикам и получать результат быстрее, дешевле и качественнее.

https://habr.com/ru/articles/941050/

#микросервисы #микросервисная_архитектура #микросервисные_инструменты #монолит #разработка_программного_обеспечения #планирование_проектов #программирование #квалификация_сотрудников #архитектура_по #архитектура_приложений

Второе пришествие микросервисов: почему в 2025 мы снова в них верим

Привет, Хабр! Недавно принял участие в панельной дискуссии про микросервисы. Планировался холивар «монолит vs микросервисы», но получился, на мой взгдяд, интересный разговор с реальными кейсами. Собрались специалисты с интересным практическим опытом: Павел Куликовский (Цифра банк), Антон Мартынов, Алексей Захаров (Axiom JDK), Андрей Почтов (АЭРО) и Александр Тырышкин (DEVTALE).

https://habr.com/ru/articles/941038/

#микросервисы #lowcode #контейнеризация #контейнеры_docker #монолит #микросервис #микросервисная_архитектура #программирование #разработка_приложений #архитектура_приложений