Знайте три основных элемента хорошего обзора дизайна

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

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

  1. Модель С4
  2. Истории пользователей и кейсы использования
  3. Дизайнерские решения

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

И самая главная из них — модель С4.

Модель C4

Почему модель C4 так важна? Прежде чем объяснять, давайте кратко представим модель C4.

Модель C4 содержит четыре C.

  1. Контекст: это обзор системы, который описывает, как пользователи взаимодействуют со всей системой. Он будет отображаться с точки зрения пользователя, поэтому детали системы не будут показаны.
  2. Контейнер: Контейнеры здесь не относятся к виртуализации контейнеров, как докер. Контейнер в модели C4 относится к объекту, который может быть развернут отдельно, например серверу API, базе данных, очереди сообщений и т. д.
  3. Компонент: Компоненты — это модули внутри контейнера. Он содержит взаимодействие между модулями или связь между доменами в дизайне, ориентированном на домен.
  4. Код: последний исходный код под компонентом. Но при описании архитектуры мы не будем показывать детали кода, достаточно уметь описывать отношения между объектами.

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

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

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

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

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

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

Это также очень наглядная схема. Похоже, он просто перечисляет различные модули. Стоит ли такая схема?

Да. Абсолютно.

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

Ce относится к количеству эфферентных связей, а Ca относится к количеству афферентных связей. Чем ближе к 0, тем стабильнее модуль, и наоборот. Что касается сцепления, у меня есть статья, в которой конкретно описывается проблема сцепления.

Для этой социальной сети модуль instability рекомендаций равен 0.8. Это означает, что рекомендация нестабильна. Пока любой модуль зависимостей изменяется, независимо от интерфейса или поведения, он прямо или косвенно влияет на систему рекомендаций.

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

Пользовательские истории и варианты использования

Как писать хорошие пользовательские истории и варианты использования я рассказал в предыдущей статье.

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

Дизайнерские решения

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

Но что такое дизайнерское решение?

Кажется, что это простое слово, но на практике это трудно почувствовать. Поэтому предлагаю простую формулу:

ПочемуA(вместоB)?

Например,

  1. Зачем использовать MySQL вместо MongoDB?
  2. Зачем использовать кеш? (вместо прямого доступа к базе данных)
  3. Зачем использовать синхронный Restful API вместо асинхронного CQRS?

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

  1. Почему мы хотим, чтобы система рекомендаций использовала синхронные вызовы для получения данных из почтовой системы?
  2. Почему эта функция разделена на две подфункции?
  3. Почему эта строка исходного кода написана именно так?

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

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

Что касается последнего кода C, давайте оставим это на усмотрение разработчиков во время проверки кода.

Заключение

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

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

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

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