Схемы проектирования архитектуры

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

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

Рекомендации по схеме

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

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

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

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

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

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

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

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

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

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

Например, ниже приведены значки для служб Майкрософт:

• Значки архитектуры Azure
• Значки Microsoft 365
• Значки Microsoft Dynamics 365
• Значки архитектуры идентификатора Microsoft Entra
• Значки Microsoft Fabric
• Значки Microsoft Power Platform

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

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

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

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

Типы схем проектирования

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

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

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

Схема контекста

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

Схема высокоуровневой системы или контейнера

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

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

Блок или функциональная схема

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

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

Схема компонентов

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

Схема развертывания

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

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

Схема потока данных (DFD)

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

Моделирование угроз безопасности, например модель STRIDE, использует специализированный DFD. На схеме показаны процессы, хранилища данных, внешние сущности, границы доверия и потоки данных, пересекающие эти границы. Он фокусируется на аннотации потоков с помощью протоколов и шифрования, а также выделяет ресурсы, требующие защиты. На этом рисунке выполняется проверка идентификации и контроля безопасности.

Схема последовательности

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

Схема пользовательского потока или пути

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

Схема связи сущностей (ERD)

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

Схема сетевого подключения

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

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

Схема состояния

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

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

Блок-схема и схема действий

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

Другие специализированные схемы

Схема на основе спецификаций

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

Примеры спецификаций схемы и моделирования:

• Модель бизнес-процессов и нотация
• Модель C4
• Модель принятия решений и нотация
• Язык унифицированного моделирования (UML)

Дальнейшие шаги