Диаграммы и шаблоны архитектуры программного обеспечения

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

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

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

Что такое архитектура программного обеспечения?

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

«Программирование без общей архитектуры или дизайна похоже на исследование пещеры с фонариком: вы не знаете, где вы были, вы не знаете, куда идете, и вы не знаете, куда именно. Ты.»

Дэнни Торп

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

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

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

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

Нужно ли нам документировать архитектуру программного обеспечения?

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

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

«Неправильная документация часто хуже, чем отсутствие документации».

Бертран Мейер

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

Что вам нужно документировать?

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

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

Хотя вы, вероятно, не хотите документировать каждое изменение кода или архитектуры, вы, безусловно, захотите задокументировать существенные изменения и, что не менее важно, почему эти изменения были сделаны.

Что делают хорошие архитектурные схемы?

Хорошие диаграммы архитектуры программного обеспечения являются источником правды и ясности. Вы хотите, чтобы ваша диаграмма быстро передавала основной состав и поведение программной системы как технической, так и нетехнической аудитории.

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

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

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

«В области программирования нет ничего более презренного, чем недокументированная программа».

Эдвард Юрдон

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

Хорошая архитектурная схема будет:

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

Основы построения диаграмм: блок-схемы, C4 и UML 2.5.

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

Блок-схемы

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

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

Пример ключа блок-схемы

На технической диаграмме каждая фигура обычно включает следующее:

• Имя представляемого элемента
• Роль этого элемента в системе
• Технология этого элемента

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

Модель С4

Модель C4 — это стандарт архитектурной документации для программных систем, который разбивает программную систему на четыре уровня:

• Контекст (уровень 1) : Диаграммы контекста представляют собой высокоуровневые концептуальные описания того, что делает ваша система, какие проблемы она решает, вовлеченных людей и любых внешних систем, которые с ней взаимодействуют. Эти диаграммы помогают составить общую картину.
• Контейнеры (уровень 2). Диаграммы контейнеров идут на один уровень глубже, описывая взаимодействия высокого уровня между приложениями или службами, составляющими вашу систему. Контейнеры могут представлять API, базы данных, файловые системы, микросервисы и т. д.
• Компоненты (уровень 3) : диаграммы компонентов рассматривают различные тела кода внутри контейнера. Эти диаграммы помогают визуализировать абстракции вашей кодовой базы.
• Код (уровень 4). Как следует из названия, диаграммы кода рассматривают архитектурные элементы, сопоставленные с кодом, такие как классы, интерфейсы, объекты и функции.

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

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

Большинство IDE (или инструментов моделирования UML) могут генерировать диаграммы кода по запросу, поэтому документацию на этом уровне детализации легче извлекать, чем поддерживать. Если компонент особенно важен или сложен, то иметь под рукой диаграммы уровня 4 может быть полезно, но в большинстве случаев вы можете подождать, пока вам не понадобятся эти диаграммы, чтобы сгенерировать их.

UML 2.5

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

Существует 14 типов диаграмм UML, которые можно разделить на две основные категории:

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

Структурные схемы	Поведенческие диаграммы
Диаграммы классов	Диаграммы деятельности
Диаграммы компонентов	Диаграммы связи
Диаграммы развертывания	Диаграммы взаимодействия
Диаграммы объектов	Диаграммы конечного автомата
Схемы пакетов	Диаграммы последовательности
Схемы профилей	Временные диаграммы
Схемы составной структуры	Диаграммы вариантов использования

В этой статье мы сосредоточимся в первую очередь на диаграммах уровней 1 и 2, поэтому не будем вдаваться в подробности.

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

Пример: система выставления счетов

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

Как минимум, ваша диаграмма должна включать:

• База данных
• Компонент бизнес-логики
• Интерфейс

Во-первых, начните с представления вашей программной системы.

Затем вы хотите задокументировать, кто такие актеры. Актеры — это все, кто будет использовать программную систему.

В этом сценарии нашими действующими лицами являются:

• Цифровые художники
• Клиенты

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

Если вы хотите пойти еще дальше, вы можете создать контейнерную диаграмму. Диаграмма контейнера фокусируется на приложениях, составляющих конкретный контейнер.

6 шаблонов архитектуры программного обеспечения

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

1. Многоуровневая (N-уровневая) архитектура

Шаблон многоуровневой архитектуры, также известный как шаблон N-уровневой архитектуры, является стандартной архитектурой, используемой для большинства приложений Java EE. Стиль многоуровневой архитектуры делит компоненты (или приложения) на горизонтальные логические уровни.

Каждый уровень играет определенную роль в системе. Один уровень может отвечать за обработку бизнес-логики, а другой — за обработку логики представления. Это демонстрирует концепцию, известную как разделение задач (SoC). Компоненты уровня будут иметь дело только с логикой внутри этого уровня. Подобное разделение слоев также упрощает тестирование и разработку программного обеспечения, поскольку сам шаблон не слишком сложен. Недостатком является то, что это не самый эффективный шаблон для использования, и его может быть сложно масштабировать.

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

• Презентация
• Бизнес
• Упорство
• База данных

Иногда бизнес-уровень и уровень сохраняемости объединяются в один уровень, особенно когда логика сохранения (например, SQL) содержится в компонентах бизнес-уровня. Небольшие приложения могут иметь всего три уровня, а более сложные приложения могут содержать пять и более слоев.

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

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

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

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

2. Клиент-серверная архитектура

В архитектуре клиент-сервер есть несколько узлов или клиентов, подключенных через сеть или интернет-соединение, которые взаимодействуют с центральным сервером.

Существует два основных типа компонентов:

• Запрашивающие службы (также известные как клиенты), которые отправляют запросы
• Поставщики услуг, отвечающие на запросы

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

Пара классических примеров приложений с клиент-серверной архитектурой — World Wide Web и электронная почта.

3. Архитектура, управляемая событиями

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

В этом шаблоне есть две основные топологии: топологии посредника и посредника.

Топологии посредника имеют четыре основных типа компонентов:

• Очереди событий
• Посредники событий
• Каналы событий
• Процессоры событий

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

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

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

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

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

Топологии брокера имеют два основных типа компонентов:

• Брокеры
• Процессоры событий

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

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

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

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

4. Архитектура микроядра

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

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

В типичной архитектуре микроядра есть два типа архитектурных компонентов: базовая система и подключаемые модули.

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

Это похоже на добавление в машину воздухозаборника для увеличения крутящего момента и мощности.

Компоненты подключаемых модулей можно подключать с помощью инициативы открытого шлюза служб (OSGi), обмена сообщениями, веб-служб или создания экземпляров объектов. Способ реализации на ваше усмотрение.

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

Если вы создаете приложение, основанное на продукте (например, Eclipse IDE), шаблон архитектуры микроядра должен быть вашим первым выбором, поскольку он позволяет вам легко добавлять дополнительные функции с течением времени.

5. Архитектура микросервисов

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

Общепринятого определения термина «микросервис» не существует. В этой статье мы определим микросервис как независимо развертываемый модуль.

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

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

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

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

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

Эту архитектуру внедряют крупные компании, такие как Amazon, Netflix и Spotify.

Существует множество способов реализации архитектуры микросервисов, но наиболее распространенными топологиями являются API на основе REST, приложения на основе REST и централизованный обмен сообщениями.

6. Космическая архитектура

Когда вы думаете о типичных веб-приложениях, большинство из них обычно обрабатывают запросы от клиентов одинаково. Клиент отправляет запрос из веб-браузера, который отправляется на веб-сервер, затем на сервер приложений и, наконец, на сервер базы данных. Когда этот тип потока данных имеет дело с большим объемом одновременно выполняемых запросов, обычно возникают проблемы с узким местом. Именно здесь вступают в действие шаблоны пространственной архитектуры (SBA). Шаблоны SBA специально разработаны для минимизации проблем, связанных с масштабируемостью и параллелизмом, за счет удаления центральной базы данных и использования вместо нее реплицированных сеток данных в памяти.

Шаблон SBA, также называемый шаблоном облачной архитектуры, используется для распределенных вычислительных систем, в которых взаимодействие между компонентами осуществляется через одно или несколько общих пространств.

В этом общем пространстве компоненты обмениваются кортежами и записями. Это подводит нас к концепции пространств кортежей или идее распределенной общей памяти.

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

Два основных типа компонентов в рамках этого архитектурного шаблона:

• Блоки обработки
• Виртуальное промежуточное ПО

Блоки обработки обычно содержат:

• Модули приложений
• Сетка данных в памяти
• Дополнительное асинхронное сохраняемое хранилище для отработки отказа
• Механизм репликации данных

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

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

Виртуализированное промежуточное ПО будет содержать четыре основных компонента:

• Сетка сообщений
• Сетка данных
• Сетка обработки
• Менеджер развертывания

Сетка обмена сообщениями — это компонент, который управляет входными запросами и информацией о сеансе.

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

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

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

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

3 общедоступные облачные платформы для разработки приложений

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

Итак, если вы знаете, что пытаетесь изобразить многоуровневую архитектуру, вы можете просмотреть существующие эталонные архитектуры, использующие этот стиль.

Вот три общедоступные облачные платформы с бесплатным доступом к сотням облачных схем эталонной архитектуры, а также инструменты для создания диаграмм!

1. Веб-сервисы Amazon (AWS)

Amazon Web Services — наиболее широко используемая на сегодняшний день платформа облачных вычислений. AWS предлагает сочетание инфраструктуры (IaaS), платформы (PaaS) и пакетного программного обеспечения как услуги (SaaS), поэтому у него есть множество ресурсов, таких как Workload Discovery [2] и AWS CloudFormation Designer [2], для создания, проверки и построение схемы архитектуры вашего приложения.

Вот пример диаграммы архитектуры AWS для компонента данных:

Компонент данных AWS

Amazon также предоставляет большую галерею, заполненную сотнями реальных архитектурных диаграмм [3]. Проверьте это!

2. Microsoft Azure

Платформа Microsoft Azure — второе по популярности решение для облачных вычислений и отличный выбор, если вы уже работаете с продуктами Microsoft. Для сотен решений вы можете просмотреть каталог эталонных архитектур.

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

Схема эталонной архитектуры Azure

Архитектуры Microsoft Azure поставляются с разбивкой потока данных, объяснением отдельных компонентов и потенциальными вариантами использования. Каждая архитектура также включает анализ производительности на основе пяти столпов Microsoft Azure Well-Architected Framework :

Надежность : способность системы восстанавливаться после сбоев и продолжать функционировать.

• Безопасность : Защита приложений и данных от угроз
• Оптимизация затрат : управление затратами для максимизации ценности
• Операционное совершенство : операционные процессы, поддерживающие работу системы в производственной среде.
• Эффективность производительности : способность системы адаптироваться к изменениям нагрузки.

3. Облачная платформа Google (GCP)

Google Cloud Platform — это набор сервисов облачных вычислений и третий по величине поставщик IaaS. GCP предоставляет фантастический ресурс для быстрого построения диаграмм: Google Cloud Architecture Diagramming Tool.

В инструменте построения диаграмм облачной архитектуры Google вы можете перетаскивать готовые эталонные архитектуры прямо на холст. Когда вы находитесь в инструменте построения диаграмм, перейдите в раздел » Диаграммы «, и вы увидите более 10 эталонных архитектур для распространенных вариантов использования.

Вот пример эталонной архитектуры для простого контейнерного приложения.

Заключение

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

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

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