Архитектурный проект: как создаются сложные программные продукты

Что это? Архитектурное проектирование в программировании можно сравнить с архитектурным проектом здания. Без него можно обойтись, если речь идет о строительстве беседки, сарайчика для тяпок и лопат. Если же мы хотим построить большое, красивое, функциональное здание, проект необходим. С программами точно так же: простой лендинг можно собрать «на коленке», серьезный продукт – только с помощью архитектурного проекта.

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

Что такое архитектурный проект в программировании

Архитектура ПО – это, в принципе, несложная система, с которой справятся инженеры даже с маленьким опытом работы. При этом непросто дать официальное определение самой системе, а точнее, разделить проект и архитектуру, потому что архитектура является одной из частей проекта.

Дейвид Гарлан и Мэри Шоу в своей книге An Introduction to Software Architecture написали, что архитектура представляет собой особенный этап проекта. Кроме того, перед тем как заниматься созданием алгоритмов и упорядочиванием информации, надо решить одну обязательную задачу – организовать общее устройство системы.

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

При этом архитектура не находится в рамках структуры программы. Специалисты из команды разработчиков архитектур IEEE утверждают, что архитектура – «концепция системы высочайшего уровня в своей среде». Исходя из этого определения, архитектура включает в себя единство концепции, экономическую целесообразность ее воплощения, эстетику программирования и дизайн.

В Rational Unified Process (RUP) архитектура концепции программы (в этой конкретной точке) – устройство или структура значимых элементов системы, которые связаны друг с другом через интерфейсы, где основа элементов – это последовательно уменьшающиеся компоненты и интерфейсы.

Развитие архитектурного проектирования

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

Эта деятельность включает в себя два понятия, которые являются проявлениями одного и того же процесса:

• Архитектура – задача.
• Проектирование – средство реализации задачи.

Узнай, какие ИТ - профессии
входят в ТОП-30 с доходом
от 210 000 ₽/мес

Павел Симонов

Исполнительный директор Geekbrains

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

Подборка содержит только самые востребованные и высокооплачиваемые специальности и направления в IT-сфере. 86% наших учеников с помощью данных материалов определились с карьерной целью на ближайшее будущее!

Скачивайте и используйте уже сегодня:

Павел Симонов

Исполнительный директор Geekbrains

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

Поможет разобраться в актуальной ситуации на рынке труда

Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка

Только проверенные нейросети с доступом из России и свободным использованием

ТОП-100 площадок для поиска работы от GeekBrains

Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽

Получить подборку бесплатно

pdf 3,7mb

doc 1,7mb

Уже скачали 32095

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

Если говорить о современной архитектуре, то сейчас главная задача стоит в создании функционального здания, а эстетика фасада отходит на второй план.

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

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

Сфера проектирования стала наиболее распространённой как современная и продуктивная форма деятельности – проект.

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

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

Стоит отметить, что в современном мире многое зависит от сферы информационных технологий в целом, а в частности от разнообразных программ, которые:

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

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

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

Такую проверку проходят только программы, которые создавались и внедрялись после того, как прошли через этап создания архитектуры ПО.

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

Фредерик Брукс, классик области информационных технологий, в своих работах выделил такие отличительные особенности программы от программного продукта:

• максимально обобщённый диапазон и виды входных данных;
• тщательная проверка;
• наличие всех необходимых документов;
• на создание и обслуживание программного продукта уходит намного больше времени.

Главные принципы архитектурного проектирования

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

• Разделение проблем. Суть принципа в том, что программа должна отличаться на основе деятельности программного продукта. К примеру, подобное можно осуществить, если отделить бизнес-модель от части создания, чтобы работники одного отдела не переживали за другие команды
• Инкапсуляция. Так можно отделить одну часть приложения от других её составляющих. Данным образом можно менять проект, не опасаясь, что изменения коснутся других частей приложения.

• Избегайте повторений. С помощью этой технологии можно избежать повторений функциональности, необходимой одному приложению. Так у вас не будет дубликатов, и можно будет создать один фрагмент кода для одного компонента. Данный принцип нужен для упрощения приложения.
• Принцип наименьшего знания(LoD (Закон Деметры)). С его помощью не возникает взаимозависимости между составляющими за счёт того, что один компонент не знает внутреннюю архитектуру программы, в которой есть другие составляющие и объекты.

7 критериев качества архитектуры проекта

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

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

Эффективность системы

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

Гибкость системы

Любую программу надо периодически изменять, потому что появляются новые требования. Если внесение изменений в приложение происходит быстро и удобно, а также не приводит к возникновению проблем и ошибок, то такая система считается гибкой и конкурентоспособной. Так что надо заранее продумывать момент возможных изменений. Задайте себе вопрос: «А что случится, если нынешнее архитектурное решение будет неправильным?», «Сколько кодов надо будет поменять в случае внесения корректив?».

Читайте также!

Программирование для школьников: как начать и не бросить

Подробнее

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

Расширяемость системы

Способность дополнять программу новыми компонентами и опциями, не меняя при этом её основную концепцию. На первых порах при разработке надо наполнять систему только основой и самыми важными функциями (принцип YAGNI — you ain’t gonna need it, «Вам это не понадобится»). Однако при этом у вас должна быть возможность запросто дополнить программу, если это потребуется.

Требование о том, чтобы архитектура программы была гибкой и поддавалась изменениям и усовершенствованию, считается очень важным, поэтому есть даже «Принцип открытости/закрытости» (Open-Closed Principle — второй из пяти принципов SOLID): программные сущности (классы, модули, функции и т.п.) должны быть открытыми для расширения, но закрытыми для модификации.

То есть программу надо создавать так, чтобы во время изменения и внесения новых опций достаточно было написать новый код и просто его добавить, не трогать при этом существующий код. Таким образом, новые требования не станут причиной изменения уже имеющейся логики, а смогут реализоваться через внесение корректировок в систему. Данный принцип – это основа «плагинной архитектуры» (Plugin Architecture).

Масштабируемость процесса разработки

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

Тестируемость

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

Дарим скидку от 60%
на обучение «Дизайнер интерьеров» до 01 декабря

Уже через 9 месяцев сможете устроиться на работу с доходом от 150 000 рублей

Забронировать скидку

Возможность повторного использования

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

Структурированный, читаемый и доступный код

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

У проекта должны быть структура и грамотно оформленный код, все необходимые документы, отсутствовать дублирование. В необычной и уникальной системе сложно разобраться. Есть даже принцип наименьшего удивления — Principle of least astonishment. Как правило, его применяют при разработке пользовательского интерфейса, но и при создании кода программы его тоже можно придерживаться.

Стоит упомянуть признаки плохого архитектурного проекта:

• В него сложно внести коррективы, так как любые перемены влияют на множество других частей программы (жесткость, Rigidity).
• Из-за внедрения новых кодов «ломаются» фрагменты системы (хрупкость, Fragility).
• Практически невозможно применить код в другой программе, потому что «вытащить» его из системы очень непросто (неподвижность, Immobility).

Зачем разрабатывать архитектуру проекта

Раньше при создании программ не создавали архитектуру проекта. Первое время это считалось правильным и удобным, потому что не надо было тратить время на «лишнее» планирование, и было быстрое прототипирование. Однако чем сложнее становились приложения, тем менее податливыми и управляемыми они были, и любое новое внедрение требовало немалых денег.

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

Вот самые популярные из них:

• Многослойная архитектура (Layered Architecture).
• Многоуровневая архитектура (Tiered Architecture).
• Сервис-ориентированная архитектура (Service Oriented Architecture — SOA).
• Микросервисная архитектура (Microservice Architecture).

Только до 2.12

Скачай подборку материалов, чтобы гарантированно найти работу в IT за 14 дней

Список документов:

ТОП-100 площадок для поиска работы от GeekBrains

20 профессий 2023 года, с доходом от 150 000 рублей

Чек-лист «Как успешно пройти собеседование»

Чтобы получить файл, укажите e-mail:

Введите e-mail, чтобы получить доступ к документам

Подтвердите, что вы не робот,
указав номер телефона:

Введите телефон, чтобы получить доступ к документам

Скачать подборку бесплатно pdf 2,5mb

Уже скачали 52300

Я подтверждаю согласие на обработку персональных данных.

Не лишним будет детальнее узнать о каждом подходе.

Многослойная архитектура проекта

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

Архитектурный проект имеет следующие слои:

• Слой представления (Presentation Layer). В нём находится пользовательский интерфейс, задача этого слоя – давать положительный пользовательский опыт.
• Слой бизнес-логики (Business Logic Layer). Название говорящее: в нём находится бизнес-логика программы. Он разделяет UI/UX и расчёты, связанные с бизнесом. Таким образом, можно быстро и просто поменять логику, чтобы подстроиться под новые бизнес-требования, которые постоянно меняются, и при этом другие слои не страдают.
• Слой передачи данных (Data Link Layer). Он ответственен за взаимодействие с постоянными хранилищами, среди которых базы данных, а также совершение обработки информации, не имеющей ничего общего с бизнесом.

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

Положительные аспекты:

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

Отрицательные стороны:

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

Многоуровневая архитектура проекта

Данный архитектурный метод делит систему программы по принципу «клиент-сервер». У архитектуры может быть один, два и более слоёв, которые разделяются между поставщиком информации и потребителем.

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

Одноуровневая система

Такой подход даёт возможность единой системе работать и на стороне сервера, и на стороне клиента. Благодаря этому развёртываемость происходит быстрее и проще, а скорость соединения выше. Помимо этого, пропадает необходимость в межсистемном взаимодействии (Inter-system communication — ISC).

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

Двухуровневая система

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

• У клиента уровни презентации, бизнес-логики и передачи информации.
• Сервер отвечает за хранилище и базу данных.

Трехуровневая и n-уровневая системы

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

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

Сервис-ориентированная архитектура (SOA)

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

В него входят 5 компонентов:

• сервисы (Services);
• сервисная шина (Service Bus);
• сервисный репозиторий (Service Repository catalogue of services);
• безопасность SOA (SOA Security);
• управление SOA (SOA Governance).

Пользователь отправляет запрос через традиционный протокол и формат данных через интернет. Запрос идёт на обработку в ESB (enterprise service bus — сервисная шина предприятия), являющуюся самым важным элементом сервис-ориентированной архитектуры, который ответственен за оркестровку и маршрутизацию.

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

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

Зачастую, сервисы бывают двух видов:

• Атомарные сервисы (Atomic services) дают те опции, которые невозможно потом изменить.
• Композиционные сервисы (Composite services). В них сочетаются несколько атомарных сервисов, благодаря чему создаётся сложная составная функциональность.

Существуют следующие типы сервисов:

• Организационные сервисы (Entity service).
• Доменные сервисы (Domain Service).
• Вспомогательные сервисы (Utility Service).
• Интегрированный сервис (Integrated Service).
• Сервис приложений (Application Service).
• Сервис безопасности (Security Service).

Mикросервисная архитектура проекта

Этот подход отличается тем, что программа создаётся как комплекс маленьких сервисов. Каждый из них действует в своём процессе и соединяется с легковесными механизмами, как правило, API для HTTP-ресурса.

• В основе этих сервисов лежат бизнес-возможности, поэтому они развёртываются отдельно друг от друга под воздействием полностью автоматического механизма.
• Централизованное управление между составляющими находится на минимальном уровне. Они могут разрабатываться на разных языках и применять отличающиеся технологии хранения информации.

Популярные статьи

Высокооплачиваемые профессии сегодня и в ближайшем будущем

Дополнительный заработок в Интернете: варианты для новичков и специалистов

Востребованные удаленные профессии: зарабатывайте, не выходя из дома

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

Как выбрать профессию по душе: детальное руководство + ценные советы

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

В архитектуру входят изолированные компактные микросервисы, которые можно дополнять отдельно друг от друга. В них содержатся такие 5 составляющих:

• сервисы (Services);
• сервисная шина (Service Bus);
• внешняя конфигурация (External configuration);
• шлюз API (API Gateway);
• контейнеры (Containers).

Читайте также!

Что такое прототип: определение, функции, тонкости разработки

Подробнее

У микросервисной архитектуры должны быть такие показатели:

• Компонентизация через сервисы.
• Ориентированность на бизнес-возможности.
• Целью являются продукты, а не проекты.
• Умные конечные точки и глупые каналы (Smart endpoints and dumb pipes).
• Децентрализованное управление.
• Децентрализованное управление информацией.
• Автоматизация инфраструктуры.
• Защита от непредвиденных ошибок.
• Проектирование с возможностью дальнейшего расширения.

Положительные аспекты:

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

Отрицательные стороны:

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

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

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

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

Автор статьи:

Редакция сайта GeekBrains Шеф-редактор раздела Программирование