в предыдущей статье«4 лично проверенных и полезных инструмента разработки и рисования»середина,Читатель оставил сообщение на заднем плане и упомянул, что хочет узнать больше о Как нарисовать архитектурную схема? Автор этой статьи обсуждает цель рисования Архитектуры, какой рисунок Архитектуры является хорошим рисунком Архитектуры и как нарисовать хороший рисунок Архитектуры.,А также подробно проанализированы классификация и примеры различных картин классической Архитектуры.,Это редкая познавательная статья,Рекомендуется лайкать и собирать!

Рисование архитектурных схем — обязательная задача для архитекторов.

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

Диаграмма архитектуры = выражение архитектуры = выражение архитектуры с разных абстрактных точек зрения и на разных уровнях абстракции. Это естественный процесс.

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

01. Назначение архитектурной схемы

Картинка стоит тысячи слов.

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

• Уточним архитектурное направление:Архитектура Диаграммы могут помочь техническим командам внести ясность.продукти техническое направление и цели,избегать вразвиватьпроцесссерединадезориентированныйилине по теме。
• Сократите расходы на связь:Волясистема Логические связи представлены графически,Графические и визуальные особенности,Позвольте команде более интуитивно понять дизайн и функциональность продукта.,Достичь консенсуса как можно быстрее и уменьшить двусмысленность;
• Повысьте эффективность совместной работы:Сотрудничество внутри и между командами、общаться、Видение и руководство。проходить Архитектура Изображения могут лучше доноситься до участников проекта。развиватьперсонал может понять более четкопродукт Общая структура и взаимосвязь между различными модулями,тем самым улучшаяразвиватьэффективность。
• Облегчает совместную работу:Архитектура Диаграммы позволяют членам команды быстросистема Полное изображение и подробности,Обеспечить совместную работу различных отделов.

Существует как минимум несколько типов целевых пользователей архитектурных диаграмм:

• Каждая команда, участвующая в проекте Роль（бизнес、продукт、развивать、тестирование и т.д.);
• Заказчики вне проекта (внешние заказчики, внешние эксперты по проверке);
• TL на всех уровнях (отчетность, взаимодействие между подразделениями, межкомандное сотрудничество и общение).

02.Какая архитектурная диаграмма является хорошей?

Критерии качества архитектурных схем (личное мнение только для справки): Картинка стоит тысячи слов.

• Четкая структура: ясная точка зрения、слойпрозрачный、Содержание понятно. Пользователи могут легко увидеть взгляды/отношения/идеи/логику, выраженные на диаграмме Архитектуры. Через диаграмму Архитектуры каждая команда понимает бизнес、Нанесите общую картину.
• Красивый внешний вид: пользователи чувствуют себя комфортно и имеют больше желания просматривать/читать. Красота отражается в различных цветах и ​​макетах: легенды понятны, цветовые типы унифицированы, и это красиво.
• Контент полный и понятный: содержание картинки самозамыкается и получается основное содержание бизнеса/функции/модуля.
• Терминология содержания единообразна, а степень детализации информации постоянна.

Конкретная реализация:

1. Смысл дизайна: четыре принципа дизайна.

• Близость: достичь организации (держать связанные элементы близко друг к другу, а дифференцированные элементы — отдельно);
• Выравнивание: сделайте страницу унифицированной и организованной (между элементами есть некоторые эффекты выравнивания);
• Контраст: усиливает эффект страницы и помогает организовать информацию (между элементами есть эффекты контраста);
• Повторение: более унифицированный и улучшенный визуальный эффект (позволяет одинаковым элементам иметь одинаковый эффект/стиль).

Примените эти принципы к линиям, блокам и граням диаграммы.

2. Красота: использование цветового круга.

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

3. Красота: метод композиции золотого сечения.

• Золотое сечение: 0,618 (общий размер изображения соответствует золотому сечению длины 1,618 и ширины 1);
• Последовательность Рибоначчи: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89..., по мере приближения к бесконечности, отношение первого члена ко второму члену становится все ближе и ближе к золоту. Сплит 0,618.

4. Ощущение завершенности: дизайн, который начинается с осознания конечной цели

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

03.Когда рисовать архитектурную схему?

1) Рисуйте перед началом сложных проектов

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

2) Когда ты думаешь, что пора рисовать (сделай это)

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

04. Классификация архитектурных схем

«Беседы архитекторов Goose Factory: как хорошо поработать в архитектурном проектировании?» 》с разных точек зрения,Для классификации Архитектуры используются различные абстрактные точки зрения: Архитектура бизнеса, Архитектура приложений, Архитектура технологий, Архитектура кода, Архитектура данных и т. д.

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

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

• Бизнес-Архитектуракартина:Бизнес-планирование、Бизнес-модуль、Бизнес-процессы и т.д.
• приложение Архитектура：микро Служитьдемонтироватьточкаизприложениеислой Второсортныйрядточка。
• Технология Архитектура: какие компоненты задействованы и как они связаны между собой.
• Архитектура кода: внутренняя диаграмма пакета приложения, диаграмма классов;
• Определенное поле: диаграмма сущности, диаграмма последовательности, диаграмма состояний, диаграмма вариантов использования и т. д.

05.Как нарисовать архитектурную схему

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

Горизонтальная многослойная конструкция:按照功能处理顺序рядточкаприложение,Например, положитесистематочкадля web Front-end/промежуточные услуги/backend-задачи — это подразделение, ориентированное на глубину бизнеса.

Вертикальное направление — это процесс стандартизации, связанный с разделением модулей и межуровневой унификацией:Стандартизация процесса обычно устанавливает конкретные стандарты.、Нормы и т. д., такие как управление безопасностью.、Управление качеством、Технические стандарты и спецификации、развивать Технические характеристики по эксплуатации и техническому обслуживанию и т. д.。

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

Существует два метода архитектурной абстракции: один — сверху вниз, другой — снизу вверх;

• Бизнес-моделирование — это абстрактный процесс восходящей индукции и дедукции от малого к большому, от части к целому;
• система Моделирование,От большого к маленькому,от целого к части,Абстрактный процесс нисходящей разборки и сегментации;
• Но это не абсолютно.

Из «Мышления в UML»:

5.2 Основные элементы схемы архитектуры: уровни, модули и функции

Горизонтальное наслоение и вертикальное деление модулей.

Наслоение:точкаслой Это также наше основное мыслительное оружие, позволяющее справляться со сложностями и управлять ими.,Цель — разъединиться. Разделите бизнес по уровням,Каждый уровень представляет собой независимый уровень логического модуля.,Каждый уровень ориентирован на решение проблем в определенной области. Нижний уровень более абстрактный.,начальствослой Более конкретный . Уровни должны быть логически связаны, чтобы нижний уровень обслуживал верхний уровень или обеспечивал поддержку возможностей.

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

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

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

5.3 Детали чертежа

Общая идея:

1. Используйте разные цвета, чтобы обозначить разные роли.
2. Изобразите отношения, соединяя линии.
3. Логическая группировка.

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

При рисовании диаграммы архитектуры необходимо учитывать ее компоненты. Чтобы обеспечить единое понимание, компоненты диаграммы архитектуры могут включать в себя:

• Рамки, различные формы, пунктирные и сплошные линии, стрелки, цвета (что означают разные цвета) и текстовый контент;
• Что обозначают пунктирная и сплошная линии? Тип компонента,тип модуля,слой,Служить,Нужно рассмотреть, реализовано ли оно и т.д.? Как передать идентификаторы разных состояний?
• Что означает стрелка? Поток данных или отношение ассоциации?
• Типы взаимодействия могут быть синхронными или асинхронными; типы ассоциации могут относиться к зависимости, наследованию и реализации.

Поддерживайте структурную и семантическую согласованность архитектурных схем:

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

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

Квадратная рамка, закругленная квадратная рамка, сфера, овал, закругленная квадратная рамка:

Можно обратиться к E-R Диаграмма также называется диаграммой сущность-связь.

Коробка:общее выражениеФункция сущности,может быть использован для выраженияслой Второсортный。

Закругленная квадратная коробка:

Обычно обработка、приложение Служить、Модуль спецификации процесса.

Круглый:общее выражениеточка подключения。

овал Круглый:Представляет состояние или процесс деятельности.。 Он также может представлять атрибуты модулей или сущностей.

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

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

Что означает цвет?

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

06. Схема архитектуры бизнеса/продукта.

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

6.1 Во-первых, установите принципы бизнес-архитектуры

Принципы бизнес-архитектуры сформулированы на основе реального бизнеса. Например, обратитесь к бизнес-платформе электронной коммерции:

（1）Волябизнес Платформизация：

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

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

（3）Изолируйте разные типыизбизнес。

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

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

6.2 Разделение модулей бизнеса/продукта, то есть диаграмма архитектуры продукта

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

Как нарисовать диаграмму архитектуры продукта?

1. Разберём бизнес-процессы и формируемый замкнутый цикл: Разобрать замкнутые циклы бизнеса и прояснить логические связи; Замкнутый бизнес-цикл: замкнутый процесс использования продукта пользователями основан на определенной потребности или проблеме пользователя.,Разобрать бизнес-процессы, используемые пользователями,Отсортируйте пользователей, роли и сценарии, участвующие в этом модуле.,Полностью выразить основной процесс,Образуйте замкнутый цикл.
2. Извлеките бизнес-требования: В зависимости от основного бизнес-процесса функциональные модули перечислены в соответствии со сценариями использования пользователя. Главное — выяснить, какие основные проблемы решает каждый функциональный модуль.
3. Определить логическую взаимосвязь функциональных модулей: На основеначальстворазберись с этимиз Функциональный модуль,Модулируйте похожие и связанные функции в простую матричную диаграмму.,Воля Функциональный модуль进行聚合точкадобрый。Обычно в плане взаимодействияслой（Вход）、бизнесслой（специфическийбизнессвязь）、Основы Служитьслой (Войти、настройки и т. д.)、данныеслой（конецслой Служитьилиданные）Подвести итог и систематизировать。

Вот несколько примеров диаграмм архитектуры продукта:

6.3 Схема бизнес-процесса

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

Какие предметы задействованы?

Какие задачи решает каждый агент?

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

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

6.4 Блок-схема задач/функций

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

6.5 [Навыки рисования]

1. Используйте разные цвета для обозначения статуса бизнеса: например, какие предприятия находятся в хорошем состоянии развития, какие имеют больше проблем, какие более стабильны, какие более конкурентоспособны и т. д.
2. Управление бизнес-группами. Объедините похожие предприятия в группу и обозначьте их пунктирными прямоугольниками или одинаковым фоном.
3. Выравнивание блоков: ради красоты вы можете изменить длину и размер разных блоков, чтобы выровнять их и сделать общий вид более красивым.

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

07. Схема архитектуры приложения.

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

Основное содержание:

Принципы применения:приложение Архитектурадизайнв принципеили ВОЗразвиватьв принципе。

Разбивка системы:Горизонтальный Наслоение:прозрачныйсистемаизслой Второсортный结构дизайн。Портретная функцияточкаразвязать：системакаждыйслой Второсортный Включатьиз Которыйприложение Служить。в ходе выполнениясистема耦合性демонтироватьточкачас,Баланс бизнеса и технической сложности,Гарантировано, что форма и дух останутся нетронутыми. система Какое приложение используется Архитектура,зависит от сложности бизнеса,В том числе стадия развития и бизнес-характеристики предприятия также зависят от технической сложности;,включать IT Стадия развития технологии и уровень внутреннего технического персонала. Сложность бизнеса (включая большой объем бизнеса) неизбежно приведет к технической сложности. Цель архитектуры приложений — избежать слишком сложных технологий при решении сложных задач бизнеса и обеспечить реализацию бизнес-архитектуры.

7.1 Взаимодействие между приложениями

(1) Принцип стабильности:

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

(2) Развязка

• Отделите стабильные части от нестабильных.
• Отделите основной бизнес от непрофильного.
• Разделите основной процесс электронной коммерции и вспомогательные процессы.
• Отсоедините приложение от данных.
• Отделите детали реализации от деталей реализации.

(3) Аннотация

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

(4) Ослабленная связь

• Асинхронные междоменные вызовы. Попробуйте асинхронно разделить разные бизнес-домены.
• Сделайте непрофильный бизнес максимально асинхронным. Сделайте основной и непрофильный бизнес максимально асинхронным.
• Если вызовы должны выполняться синхронно, необходимо установить время ожидания и длину очереди задач.

(5) Отказоустойчивая конструкция

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

Диаграммы архитектуры приложений можно разделить на диаграммы архитектуры функций/модулей приложения и диаграммы архитектуры отдельных технологий приложений.

7.2 Схема функциональной архитектуры приложения

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

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

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

7.3 Схема архитектуры технологии единого приложения

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

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

7.4 Временная диаграмма, также известная как диаграмма последовательности и диаграмма последовательности

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

08.Техническая схема архитектуры

Техническая архитектура. Определите фактически работающие компоненты, составляющие систему приложений (lvs, nginx, tomcat, php-fpm и т. д.), взаимосвязь между этими работающими компонентами и стратегию развертывания на оборудовании. Выделите техническую реализацию и сосредоточьтесь на описании ключевых технических компонентов системы, таких как многоуровневость, основные технические компоненты, методы восходящей и нисходящей связи, поток данных и т. д.

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

Принципы проектирования технической архитектуры заключаются в следующем:

(1) Без сохранения состояния, то есть старайтесь не сохранять данные о состоянии на локальном компьютере.

(2) Многоразовый.

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

(3) Ослабленная связь

• Звоните между бизнес-доменами и максимально отделяйте их асинхронно.
• Установите тайм-аут и размер очереди при синхронном вызове.
• Отделите относительно стабильную базу Служить от нестабильных процессов Служить.

(4) Принцип управления

• Служить можно понизить.
• Служить Ограничиваемый ток。
• Служить Переключаемый。
• Служитьконтролируемый。
• Механизм белого списка.
• Заключить договор Служить.

(5) Базовые услуги

• Фундамент Служить тонет、Многоразовые, например, своевременность、Инвентаризация и расчет цен.
• Базовая Служить автономией и относительной независимостью.
• Реализация базового Служить должна быть упрощенной и горизонтально расширяемой.
• Реализация базового Служить должна быть физически изолирована.,Включает базовые данные, связанные со Служить.

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

Другие соответствующие фотографии, взятые из Интернета:

09.Схема архитектуры кода

Многоуровневое кодирование позволяет различным уровням кода выполнять разные действия. Четкий многоуровневый код улучшает читаемость. Из структуры кода можно примерно понять, как код состоит из слоев и каковы приблизительные функции каждого уровня. Например, обычно используемая трехуровневая структура кода Controller, Service и Mapper/Dao имеет логическую область действия кода каждого уровня.

Диаграмма архитектуры кода также включает диаграмму uml:

10. Схема архитектуры данных.

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

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

Принципы проектирования архитектуры данных заключаются в следующем:

(1) Единое представление данных, то есть обеспечение своевременности, последовательности, точности и полноты данных.

(2) Принцип согласованности данных:

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

(3) Разделение данных и приложений.

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

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

(5) Чтение и запись базы данных разделены.

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

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

(7) Разумно использовать базы данных NoSQL. Когда база данных имеет возможность поддерживать это, постарайтесь не вводить кэширование. Кроме того, кэш следует рационально использовать для аварийного восстановления.

-End-