Я занимаюсь разработкой архитектур решения и учу других создавать лучшие диаграммы архитектуры решения на протяжении десятилетий и всегда придерживался принципа «диаграмма превыше всего». В результате я видел много отличных диаграмм архитектуры решения. Однако также приходилось встречать и не слишком впечатляющие примеры. У меня сформировались твердые убеждения относительно того, какие графические нотации лучше всего подходят для архитектуры решения. Однако в данной статье я воздержусь от навязывания своего мнения и вместо этого дам несколько советов, которые будут полезны вам независимо от того, какой подход вы предпочитаете.
№1 Начните с названия
Каждую диаграмму следует начинать с самой простой вещи: названия. Название важнее, чем вы думаете: в первую очередь его добавление определяет содержание вашей диаграммы. Как вы можете создать понятную диаграмму, если не знаете, что изображаете? Первый шаг для разработки лучших диаграмм архитектуры решения — это четкое понимание того, что вы изображаете.
Название — это местоположение «Вы здесь» на общем плане вашей диаграммы. Оно помогает вам и зрителю сориентироваться, перед тем как погрузиться в работу.
Я расширил понятие «название», чтобы включить в него основную информацию о диаграмме.
Условное обозначение (Нотация). Это позволяет аудитории понять, какой язык вы используете для рассказа о своей архитектуре. В том случае, если вы применили стандартную нотацию (внимание, спойлер: об этом будет рассказано ниже), укажите, что именно вы задействовали. Если вы этого не сделали, не беда, но тем не менее я рекомендую указать, что это за диаграмма, например, "Поток данных".
Общая информация о содержимом (Скоуп). Это считалось бы обычным названием, если бы вы не добавили рекомендованную мной дополнительную информацию. Это наименование вашей диаграммы, которое и определяет ее область применения. В нем должно быть как можно меньше слов, чтобы правильно передать скоуп диаграммы. Обычно в диаграмме архитектуры решения скоуп — это наименование решения. Однако в некоторых случаях можно создать несколько диаграмм с различных ракурсов, поэтому следует выбирать более подробные описания, например, "Портал продаж — представление клиента".
Дата. Все сведения получают дополнительные преимущества благодаря указанию срока их свежести! Дата поможет вашей аудитории определиться, какой из представленных вариантов диаграммы самый актуальный. Кроме того, это позже позволит кому-либо узнать возраст информации, которую он просматривает.
Версия. Порядковый номер версии упрощает для кого-то понимание о том, что у него самая последняя диаграмма. Обычно я использую трехзначное обозначение — [версия решения].[версия публикации диаграммы].[внутренняя редакция диаграммы].
Название очень важно по двум основным причинам:
Оно подсказывает вам основные принципы построения диаграммы, над которой вы работаете, что помогает вам не отклоняться от цели.
Оно предоставляет вашей аудитории информацию о том, что именно они видят, что значительно облегчает понимание диаграммы.
№2 Используйте правильные диаграммы архитектуры решения
Я знаю. "Используйте правильную диаграмму" звучит как нелепость, но это не так! Для определенных типов коммуникации лучше применять отличные друг от друга диаграммные нотации. Некоторые форматы диаграмм точнее отображают потоки. Другие лучше подходят для статичных соединений. Какие-то получаются более симпатичными при использовании Powerpoint, но при этом они приносят в жертву точность ради внешней привлекательности (обращаю внимание на диаграмму архитектуры концептуального решения).
Выбор наилучшего формата диаграммы для информации, которую вы хотите передать, имеет огромное значение. Иногда, пытаясь быстро изобразить какой-либо аспект архитектуры решения, и чувствуя, как бьюсь головой о стену, я понимаю, что использую неправильную диаграмму. Легче создать лучшую диаграмму архитектуры решения, если вы работаете с правильной нотацией; это как забивать гвоздь молотком, а не отверткой.
№3 Не следует перегружать одну диаграмму, создавайте несколько
Хотя создание большего количества диаграмм может выглядеть неинтуитивным, наличие нескольких графиков, каждый из которых является "правильной диаграммой" для передачи определенного аспекта архитектуры решения, делает его более простым и понятным для вашей аудитории. Хотя для этого им придется просмотреть несколько вариантов. В Wittij Consulting у нас есть стандартный набор диаграмм архитектуры решения, разработанных под любую архитектуру, над которой мы работаем:
Диаграмма компонента
Каждая из них сфокусирована на отдельном аспекте архитектуры. Рекомендация относительно того, как не перегружать диаграмму, применима и к определению ее объема. Иногда две диаграммы информационного потока более понятны, так как из-за большого количества блоков и линий в рамках одной схемы можно запутаться.
№4 Используйте стандартные нотации
И вы, и ваша аудитория выиграете, если выберете стандартный набор обозначений для диаграмм архитектуры решения.
Преимущество заключается в том, что, освоив нотацию диаграммы, вы не тратите время на ее обдумывание и вместо этого можете сосредоточиться на архитектуре, которую пытаетесь изобразить. Это похоже на свободное владение языком: прежде чем вы обретете способность легко говорить, необходимо приложить значительные усилия, чтобы определить правильное слово для передачи той или иной мысли. Чем более свободно вы владеете языком, тем меньше эта проблема. Вы можете быстрее и правильнее донести до другого человека то, о чем вы думаете.
То же самое верно и для вашей аудитории. Если бы вы пытались объяснить свою архитектуру на немецком языке, но ваши слушатели им не владеют, вам пришлось бы гораздо медленнее (и с большим разочарованием для них) сначала их ему обучить, чтобы они смогли понять то, что вы хотите разъяснить. С составлением диаграмм все точно так же, любые усилия аудитории, затрачиваемые для понимания вашего графика, отвлекают ее от процесса изучения архитектуры решения.
Предположим, что каждый раз, когда ваша аудитория видит диаграмму архитектуры, то она схожа с предыдущей. В этом случае они изучают нотацию, после чего анализ диаграммы становится интуитивно понятным, и можно полностью сосредоточить внимание на представленной архитектуре.
Все то, что на диаграмме архитектуры решения не делает вашу архитектуру решения более понятной, становится помехой, которая затрудняет понимание архитектуры решения вашим зрителем.
Я сторонник принятия стандартной отраслевой нотации. Таким образом, вы получаете выгоду от уже имеющихся знаний, инструментов и квалифицированных специалистов. Не говоря о "пробах и ошибках", с помощью которых эта нотация была усовершенствована. Очевидно, что легче создавать лучшие диаграммы архитектуры решения, если использовать нотацию, разработанную специально для этого! Мы в основном используем UML.
Но даже если вы предпочитаете выбрать что-то другое или даже создать свой собственный подход, целесообразно все же остановиться на чем-то одном, а не придумывать все заново каждый раз, когда вы создаете диаграмму.
№5 Отбросьте это!
Все на диаграмме архитектуры решения, что не делает архитектуру вашего решения более понятной, становится помехой, которая затрудняет понимание архитектуры вашим зрителем. Вот почему меньше — всегда лучше. Ясность диаграммы архитектуры зависит как от того, что вы оставите за ее пределами, так и от того, что включите в нее.
После того как вы закончите работу над диаграммой архитектуры решения, я рекомендую вам пересмотреть ее заново и определить, что можно удалить со страницы без потери важной информации. Поверьте мне, вы обязательно что-нибудь найдете. Если на вашей диаграмме так и не появилось достаточно полезной площади, вам нужно продолжать удаление или последовать вышеупомянутому совету по созданию нескольких соответствующих целевому назначению диаграмм.
Лучшие диаграммы архитектуры решения
Мне еще многое нужно сказать о создании лучших диаграмм архитектуры решения, но это все советы на сегодня! Архитектура решения — это, прежде всего, способ оказания помощи в работе, поэтому умение четко доносить свою идею — важный навык. Это сочетание искусства и науки. Изучение инструментов и методов может помочь вам пройти часть пути, а практика позволит преодолеть все остальное. Если вы уже начали это путешествие, ознакомьтесь с другими нашими статьями о составлении диаграмм.
Скоро состоится открытое занятие «Как аналитику спроектировать свой REST API». На уроке рассмотрим:
— как понять, что он нужен;
— с чего начать и где искать требования;
— что от меня будет нужно разработчику;
— как самому протестировать.
Все заинтересованные могут зарегистрироваться на вебинар по ссылке.
