инструменты для проектирования архитектуры приложения
В чем нарисовать архитектуру приложения?
OpenOffice Draw крайне неудобен, А4 слишком мал, Pain слишком долго и неудобно, в голове держать нереально все.
Есть спец софт? Или онлайн рисовалки?
Простой 9 комментариев
Майндмап в свободном стиле, держится на порядки дольше
В мс офис есть визио для подобного, но он также не взлетает
sim3x, нууу, в принципе верно. Так как что уже дальше менее важно нежелеи на самом начале. Изначально надо построить более менее поддерживаемую архитектуру с возможностью допилки модулями.
Я вот сделал сайт, а теперь спустя 4 месяца, сижу Doctrine изучаю, архитектурки смотрю на гите, ресую по новой все, читаю статейки. Ибо каждая правка ломает все на сайте. Изначально думал что 1 класс на все это гуд, вот и запелил. Контроллер который отвечает за юзера, посты и настройки юзера и прочую срань.
Проще будет переписать по новой, только правильно)
Ибо имхо, сидеть поиск на сайте править 2 дня.
Визуально вроде ниче так, а код какаха полная)
Так как что уже дальше менее важно нежелеи на самом начале.
Поддерживать и допиливать сложнее, чем пилить с 0
Начните с ТЗ и ТДД
sim3x, я в общем то начал посматривать на Symfony, более опытные разрабы сказали что он более гибок для ентерпрайз. Laravel это как ясли, он идеален для small / medium projects. Вполне возможно, что скоро пойдет новая серия вопросов по Symfony. Надо более детально разобрать для себя. Я хочу что бы система была гибкой и расширяемой. Хотя я и делал все по докам и по гуглу. Теперь у меня куча кода, правка в одном месте, ломает половину сайта, и надо править все.
ТЗ то было, и есть, дело в том что когда начинал, не задавался вопросами что лучше, Doctrine или Eloquent, я и не знал что такое есть вообще, а просто смотрел видосики и гайды в инете.
Не вижу способа организации и структуризации кода на Eloquent, особенно, когда речь идет о SOLID. Думаю это несовместимо с Eloquent вообще. А использовать Doctrine как я сейчас делаю в одном проекте на работе, ну такое, весьма костыльно как по мне, ибо в Symfony он встроен. Все в инете говорит о том что Симфони больше подходит под ентерпрайз, поетому у него оценка меньше. Так как мелких проектов меньше. Симфони более строг, порог входа выше, за то более гибкий, хотя больше коду.
Хотя он все же очень сильно помогает сделать архитектуру более гибкой в Ларе. Нет больше контроллеров на 2 000 строк, и моделей на 1 000 строк. Мне доктрина в общем то понравилась.
Andrew Stark, у вас преждевременная оптимизация и много размышлений о высоком
Если не получится написать с первого раза выкиньте все и напишите заново
Архитектура IT-проекта с Attribute-Driven Design
Архитектура приложения — это его технологическая база, которая учитывает риски проекта, бюджет, требования и ограничения, потребности в масштабировании.
Помимо разработки архитектуры, на старте требуется приблизительно оценить объем и стоимость проекта. Для этого мы в своей практике используем одну из проверенных методологий создания архитектуры ПО — Attribute-Driven Design (ADD). При этом мы опираемся на атрибуты качества того или иного IT-продукта. На их основе мы на этапе оценки (пресейла) создаём архитектурную концепцию системы.
Рассмотрим этапы работы с архитектурной концепцией, возможные сложности и решения, исходя из опыта нашего Архитектурного комитета. Мы надеемся, что статья будет полезна архитекторам и разработчикам, желающим освоить методологию ADD, и может быть интересна смежным специалистам.
Именно IT-архитектор решает, как в конечном итоге будет выглядеть информационная система — в целом и в деталях. Ему требуется найти баланс между конкурирующими требованиями и ограничениями.
Если у вас есть детальное архитектурное решение, это позволит наиболее точно оценить сроки и стоимость реализации продукта. Кроме того, появляется возможность уже на старте определить характеристики системы, которая будет соответствовать бизнес-задачам. Среди критериев качества архитектуры – гибкость для масштабирования, снижение рисков, скорость работы и возможность независимого выбора подрядчиков.
О том, как выглядит день архитектора, и о наиболее требовательных к архитектуре проектах мы рассказывали ранее на Хабре и в нашем подкасте.
Требования и ограничения
Наша цель — спроектировать архитектуру систематическим, предсказуемым и экономически эффективным способом. Для этого нужно определить требования к продукту.
Как правило, техническое задание (ТЗ) на разработку продукта содержит требования, но не всегда они указаны в достаточном объеме. По этой причине в числе ключевых задач IT-архитектора – сбор и анализ требований, создание дизайна архитектуры и описание решения, его проверка, а также контроль и надзор во время разработки ПО.
Рассмотрим, что входит в список требований:
Цель проектирования
От цели зависит, что нам нужно на старте: детальная архитектура или приблизительное представление об устройстве системы, которое позволит оценить объем и стоимость работ.
Атрибуты качества, нефункциональные требования
Эти атрибуты определяют свойства системы, которые она должна демонстрировать — требования к производительности, доступности, безопасности, удобству использования.
Пример: система должна работать 24х7, допускается простой не более 30 минут в месяц.
Функциональные требования
Определяют действия, которые система способна выполнить.
Пример: возможность выгружать данные из файла и рассылать отчеты по email.
Системные требования
Возникают постепенно в процессе детализации и реализуются итеративно.
Пример: авторизация, ведение журнала действий, кэширование.
Ограничения
Не относятся напрямую к поведению системы и не поддаются нашему влиянию. Например, у клиента есть пожелания по разработке микросервисной, а не монолитной архитектуры. Также сюда относятся требования законодательства, например, в области хранения персональных данных.
Как правило, владелец продукта заранее не имеет полного списка требований к системе, поэтому архитектор непосредственно организует процесс их сбора и фиксации. Из всех требований к системе специалист обязан выделить архитектурно значимые, которые оказывают глубокое влияние на конечное решение.
Согласно методологии ADD, сбор требований – это первый этап работы. Его назначение:
— помочь оценить стоимость и график работ;
— выработать ключевые технологии;
— обеспечить достижение бизнес-целей в процессе разработки.
Далее рассмотрим остальные этапы проектирования.
Обзор методологии
1) Собираем требования
В качестве источника могут выступать результаты опросов стейк-холдеров, анализ бизнес-целей проекта и историй использования (user story). При этом важно конкретизировать, что имеет в виду клиент. Например, не просто «безотказная работа сайта», а «допустимый период простоя – 30 минут в месяц».
Далее мы оцениваем важность требований по двум критериям:
ценность для бизнеса;
степень влияния на архитектуру.
Уровни важности оцениваем по шкале HML (high, medium, low — высокий, средний, низкий). Таким образом, каждое требование будет иметь двухбуквенное сочетание. Архитектурно значимые пункты имеют обозначения HH, HM, HL, MH, MM. Стоит отметить, что большое число требований HH означает высокие риски на проекте.
2) Проектируем архитектуру
Мы проектируем архитектуру ПО, исходя из наиболее значимых атрибутов качества. Это рекурсивный процесс, в ходе которого система декомпозируется на более мелкие подсистемы.
ADD — первый метод, который концентрируется на атрибутах качества и способах их достижения. Важным вкладом ADD было признание того, что анализ и документация являются неотъемлемой частью процесса проектирования. Этот метод успешно применяется более 15 лет.
Сейчас актуальная версия ADD — 3.0, итеративная. Согласно ей, проектирование выполняется поэтапно в течение всего времени разработки системы, в каждом спринте. В ней по шагам описано руководство по тем задачам, которые необходимо выполнить в рамках каждой итерации.
Шаг 1. Проверка входных данных
Убеждаемся, что все необходимые данные и требования доступны, приоритизированы, корректны и выполнимы, а цель работы понятна.
Шаг 2. Определяем список требований к подсистеме
Ранжируем требования по важности для бизнеса и степени влияния на архитектуру, группируем в соответствии с оценкой HML, выбираем 5-6 приоритетных. Устанавливаем цель каждой итерации.
Шаг 3. Выбираем часть системы для проектирования
Исходим из риска и сложности реализации, ценности для бизнеса, критического пути и точности проработки требований. Строим работу на достижении требований, которые соответствуют целей итерации
Шаг 4. Определяем лучший вариант из возможных
Самый сложный пункт. Анализируем все варианты, находим преимущества и недостатки.
Шаг 5. Конкретизируем компоненты выбранной концепции, определяем обязанности и интерфейсы
Как правило, в начале работы концепция формулируется в общем виде. На данном этапе мы определяем все элементы подсистемы и ответственность каждого, выбираем интерфейс, через который компоненты взаимодействуют между собой.
Шаг 6. Делаем эскиз решения и краткое описание
Оформляем описание в наглядный документ, например, в виде UML-диаграммы или SFML. Нужно также зафиксировать все принятые решения, описать, на какие компромиссы мы пошли и какие альтернативы рассмотрели. Это поможет в дальнейшем оценить аргументы в пользу конкретной архитектуры и создать документацию.
Шаг 7. Проверка выполнения требований
На этом шаге методология рекомендует получить “второе мнение” других опытных коллег-архитекторов, для того чтобы подойти к процессу более объективно. Участие нескольких специалистов с их опытом и точкой зрения на архитектуру поможет оперативно выявить недочеты, если они есть.
Мы уточняем и конкретизируем требования, расставляем приоритеты и затем повторяем шаги со 2 по 7 в каждой итерации. Таким образом необходимо проработать все требования с высоким приоритетом, соблюдая все ограничения. Но не обязательно проводить итерации последовательно. Скорее всего, вы будете чередовать этапы проектирования и реализации системы.
3) Отслеживаем прогресс
Чтобы вовремя выполнить перечисленные выше шаги, архитектору нужно наблюдать за прогрессом работы команды и оперативно откликаться на изменения. Авторы методологии советуют отслеживать выполнение шагов с помощью архитектурного бэклога в виде канбан-доски. В ее столбцы мы помещаем архитектурно значимые требования, ограничения и системные задачи. Они могут иметь следующие статусы:
Not Yet Addressed (Еще не рассмотрено)
Partially Addressed (Рассмотрено частично)
Completely Addressed (Рассмотрено полностью)
Рассмотрим на примере
В заключение расскажем на примере о том, как закладывается архитектура по ADD.
Задача
К нам обратился зарубежный заказчик — владелец крупного хранилища данных, полученных из старинных газет (более 1 млрд отсканированных страниц). Заказчику потребовалось найти и собрать в единую базу знаний все брачные объявления, а также записи о свадьбах: кто, когда и на ком женился.
Чтобы обработать информацию и выделить нужные факты, мы использовали нейросеть. Инженеры заказчика ранее уже создали все необходимые модели TensorFlow, которые должны запускаться последовательно, образуя конвейер. На вход модели поступал результат работы предыдущей модели, преобразованный по определенному алгоритму. Модели работали с разной скоростью и имели разные требования к ресурсам (потребление оперативной памяти, нагрузка на процессор, потребность в GPU).
Чтобы выполнить проект в срок, мы определили, что в среднем нужно обрабатывать до 10 миллионов страниц в день. Запросы на обработку поступали неравномерно, в некоторые часы их количество было близко к нулю, в другие — составляло порядка одного-двух миллионов. Страница полностью обрабатывалась не позднее чем через час после поступления.
Заказчик планировал развернуть систему в облаке. Поэтому было важно оптимально использовать вычислительные ресурсы, чтобы минимизировать плату за их аренду.
Варианты использования
Вариант использования
Описание
Извлечение фактов из текста
На вход системы подается отсканированный текст. На выходе получаем JSON с извлеченными фактами на интересующую нас тему.
Атрибуты качества
Атрибут
Описание
До 10 миллионов страниц в день. Результат обработки страницы должен быть получен не позднее чем через 1 час.
Система должна уметь справляться с ростом нагрузки. Она неравномерная: от 0 до 2 миллионов запросов в час.
Необходимо оптимально использовать вычислительные ресурсы, чтобы минимизировать плату за их аренду.
Ограничения
Описание
Система должна быть развернута в облаке AWS.
Использовать для вычислений готовые модели TensorFlow. Модели работают с разной скоростью. Требования к ресурсам сильно отличаются: некоторые потребляют много оперативной памяти, другие сильно нагружают процессор, третьим для работы необходим GPU.
Архитектурные задачи
Описание
Спроектировать и описать высокоуровневую архитектуру системы
Процесс проектирования
После фиксации требований мы подготовились к тому, чтобы начать первую итерацию ADD.
Шаг 1. Проверка и анализ исходных данных
Категория
Детали
Категория
Детали
Спроектировать систему с нуля. Работа должна быть выполнена в виде последовательных коротких итераций, чтобы оперативно получать обратную связь.
Спроектировать систему с нуля. Работа должна быть выполнена в виде последовательных коротких итераций, чтобы оперативно получать обратную связь.
Как проектируют приложения: разбираемся в архитектуре
Старший iOS-разработчик из «ВКонтакте» рассказывает, почему архитектура не главное в проекте и как сделать продукт поддерживаемым и масштабируемым.
Катя Павловская для Skillbox Media
Евгений Ёлчев
Старший iOS-разработчик во «ВКонтакте». Раньше был фулстеком, бэкендером и DevOps, руководил отделом мобильной разработки, три года преподавал iOS-разработку в GeekBrains, был деканом факультета. Состоит в программном комитете конференции Podlodka iOS Crew, ведёт YouTube-канал с видеоуроками по Flutter. В Twitter пишет под ником @tygeddar.
Я люблю спорить о том, какая архитектура лучше. Может, из-за своего внутреннего перфекциониста или диплома архитектора информационных систем, а может, потому, что мне лень копаться в плохих проектах.
Спойлер: больше всего я люблю архитектуру MVC. Дальше расскажу, как она работает и почему мне не нравятся всякие MVVM, MVP и VIPER. Кстати, недавно я разобрался во Flux и её имплементации Redux и понял, что их я тоже недолюбливаю.
В основе статьи — тред автора в Twitter.
Что такое архитектура MVC
Я тогда был студентом, делал курсовые и пет-проекты. У них была сложная вёрстка и непростая структура БД, но максимально простая логика. Код получался простым, но в целом меня такой подход устраивал.
Мне не приходило в голову, что можно делать не так, как написано в документации к инструментам и в примерах на форумах. Я был счастлив и не забивал голову чепухой.
Я пробовал поменять логику в своём проекте — перенёс её из одного файла в другой, но разницы не заметил. По факту ничего и не изменилось, только код теперь лежал в другом файле.
Изучая дискуссии в интернете и рассуждая самостоятельно, я понял, что «толстая» модель мне не нравится. Пусть лучше модель остаётся базой данных, а контроллер и дальше управляет логикой.
Со временем мои проекты становились всё сложнее, а контроллеры пухлее (правда, не как UIViewController в iOS). Я пробовал с этим бороться, выносил логику в сторонние файлы, которые включал в контроллеры, но это мало что меняло: архитектура сохранялась, просто код переносился из одного файла в другой.
Почему MVC не работала в моих проектах
В 2013 году я пересел на Laravel, разобрался с автозагрузкой классов в PHP, начал разбираться с ООП и прочитал «Совершенный код» Стива Макконнелла.
Стало ясно, что не стоит складывать всё в один файл — код и классы должны организовывать структуру, а некоторые фрагменты кода лучше убрать из MVC и выделить в самостоятельные части, которые можно переиспользовать.
С этого момента я начал писать проекты по-другому. В них появились иерархии классов, которые хранили логику, а контроллер сильно похудел — он получал данные от базы, передавал их в разные пакеты, получал от них результат и отправлял на HTML-страницу.
Архитектура проектов не была идеальной, потому что не подошла бы ни для одной сложной системы. Но для моих целей она была крутой и удобной: код получался читабельный, а все элементы проекта оставались довольно независимы.
Как я делал систему управления
VDS-сервером
В сложной системе нельзя передавать все данные через один контроллер, поэтому каждый плагин отдельно реализовывал веб- и API-интерфейсы, доступ к данным и бизнес-логику, вынесенную в пакеты для переиспользования.
Получилось так: HTML ⟷ JavaScript (модели, общение с API) ⟷ API ⟷ переиспользуемые пакеты ⟷ бизнес-логика и доступ к данным. Всё это не было похоже на MVC.
Почему архитектура не главное в проекте
Когда я увидел, как это реализуют в других компаниях, то осознал несколько важных нюансов.
Архитектура не даёт преимуществ. Ни одна продвинутая архитектура не была лучше того, что я делал в самом начале. За всё время я перепробовал разные подходы и поэтому мог оценить их пользу для проекта. Но между MVC и MVP не было разницы — кроме названий классов и правил вроде тех, когда элементы вызывают друг друга.
Компании понимают архитектуру по-разному. Одни говорят, что используют MVVM, у других то же самое называется MVC. Я видел пять MVVM-систем, и все были разными. Исключение — VIPER, у которой благодаря Егору Толстому есть подробная документация и много примеров. Но даже там были отличия.
Популярная архитектура не значит лучшая. Выбирать архитектуру из-за мейнстримности бесполезно. Кто-то решает использовать MVVM, но одни и те же компоненты кладёт в разные части проекта.
Архитектура не спасёт проект. Сама по себе она не решает проблемы и не гарантирует успеха.
Что же такое MVC на самом деле
Я постоянно изучал архитектуры, читал книги и спорил с коллегами, несколько раз пересматривал идею MVC в языке Smalltalk и несколько раз менял к ней отношение.
В итоге я понял, что MVC — это не три файла, и даже не несколько классов для каждого элемента. Модель — не про данные и не про бизнес-логику, а контроллер давно не нужен, и пора использовать MV.
Приложения с бизнес-логикой и доступом к данным были и до MVC, им не хватало только пользовательского интерфейса. Главная задача MVC — связать UI со всем остальным. Единственная рекомендация от создателя — при надобности создавать для каждой View свой фасад для Model и слушать его через паттерн-наблюдатель.
View — это и есть пользовательский интерфейс, Model — остальное приложение. Задача Controller — не быть прослойкой между V и M, а всего лишь принимать информацию от пользователя.
Принцип MVC — не мешать UI с бизнес-логикой, базой данных и другими частями приложения. А как это реализовать, уже пускай думает архитектор. Это не космическая инженерия.
Важно понимать, что MVP, MVVM или VIPER не заменяют MVC, а только дополняют её. Контроллер уже не нужен, потому что за ввод данных отвечает View, это стало его неотъемлемой частью.
Получается, что MVC в Apple, MVVM и другие варианты — это MV, где контроллер убрали за ненадобностью. Из всех современных MV(x) именно MVVM больше всего похожа на каноническую MVC.
Все эти термины усложняют общение. Иногда сложно понять, о чём тебе говорят, хотя задача архитектуры в том, чтобы всё было проще и понятнее.
Как разобраться в любой архитектуре
Может показаться, что все архитектуры одинаковые, и им вообще не стоит уделять внимания. Но это не так. У меня есть несколько правил.
Главное — реализация. Глобальная архитектура не так важна, как её воплощение. Всё зависит от того, как вы называете классы, где храните элементы и как классы общаются между собой. Все из команды должны соблюдать ваш стандарт, и тогда проект будет проще поддерживать.
Model — ваша ответственность. Архитектура MVC не даёт инструкций, как правильно написать основную часть приложения. Ваша ответственность в том, чтобы не устраивать в Model кашу, где половина классов — Service, а вторая половина — Helper.
Нужно разбираться в основах. Не стоит изучать конкретную архитектуру, лучше понять, из чего она логически следует. Тут поможет история, объектно-ориентированное и функциональное программирование, паттерны, SOLID и всё остальное. Обязательно надо прочитать «Совершенный код» Стива Макконнелла.
С какого-то момента я начал теряться в проекте. У меня появилась куча сущностей с похожими названиями и похожими данными, я создал миллиард экшенов. В итоге сам запутался, что, как и с чем взаимодействует.
Redux хороша для больших проектов, ориентированных на офлайн, где одновременно происходит куча асинхронных неблокируемых событий. Там этот бойлерплейт стоит терпеть, потому что он спасёт вам жизнь. Но в обычном тонком клиенте лучше использовать стандартную MV и не париться.
Вывод: что прочитать об архитектуре
На «Хабре» есть отличные статьи об MVC — «Охота на мифический MVC. Обзор, возвращение к первоисточникам и про то, как анализировать и выводить шаблоны самому» и «Охота на мифический MVC. Построение пользовательского интерфейса». Обязательно прочитайте их, если интересуетесь архитектурой — автор тщательно и на хороших примерах разобрал, что это такое.
Zend Framework — открытый объектно-ориентированный фреймворк для PHP 5. Переименован в Laminas Project.
Если контроллер тонкий, то логика заложена в модели, а если толстый, то в самом контроллере.
UIViewController — это класс во фреймворке UIKit от Apple. Чтобы собрать UI-приложение, для него нужно создавать подклассы.
VDS-сервер — виртуальный выделенный сервер, то же, что и VPS-сервер. Эмулирует работу физического выделенного сервера. У него есть root-доступ и возможность устанавливать нужные ОС и ПО.
Синхронный код выполняется сразу, асинхронный — только в нужный момент. Например, когда загрузится изображение или ответит удалённый сервер.
UIKit — фреймворк, на основе которого строят фронтенд приложений для iOS и tvOS.
Model-View-ViewModel — один из вариантов архитектуры приложения. View отвечает за интерфейс и пользовательский ввод, ViewModel — посредник между UI и логикой.
Model-View-Presenter — шаблон архитектуры, производный от MVC. Presenter выполняет ту же роль, что и Controller, но также отвечает за пользовательский ввод.
Аббревиатура VIPER обозначает View — Interactor — Presenter — Entity — Router. Архитектура часто используется в iOS-разработке.
Flux — это архитектура, которая используется в проектах на фреймворке React для JavaScript.
Redux — открытая библиотека для JavaScript. Нужна, чтобы управлять состоянием приложения. Помогает писать клиентские и серверные программы.
Middleware — промежуточное ПО, которое помогает приложению и серверу обмениваться запросами. Например, middleware может связать новую программу со старым API.
Редюсер (reducer) — это функция, которая получает состояние (state) и действие (action) и возвращает следующие. Её задача — сделать так, чтобы приложение реагировало, когда пользователь вводит новые данные, кликает по элементу мышью и так далее.
Бойлерплейт — код, который вставляют в приложение почти без изменений. Иногда одни и те же шаблоны кода копируют в разные части приложения.
Flutter — SDK и фреймворк от Google, созданный для разработки нативных мобильных приложений для iOS и Android.
SwiftUI — это комплект инструментов, в которых создают пользовательский интерфейс iOS-приложений.