Автор | Сяо И Старший технический эксперт Ali Entertainment

Подпишитесь на официальный аккаунт «Alibaba Cloud Native» и ответьте на фреймворк, чтобы увидеть четкую общую картину знаний!

**Введение: **Что такое архитектурная диаграмма? Зачем рисовать архитектурную схему? Как нарисовать хорошую архитектурную схему? Какие существуют методы? Эта статья начинается с определения архитектуры, делится многолетним опытом Сяо И, старшего технического эксперта Ali Entertainment, по рисованию архитектурных диаграмм и подробно обсуждает концепцию абстракции. Содержание длинное, и учащиеся могут собрать его и внимательно прочитать.

Что такое архитектурная диаграмма?

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

架构图 = 架构 + 图

Следуя этому уравнению, мы можем преобразовать проблему в:

Что такое архитектура?
Что такое картина?

Что такое картина? Ответить на этот вопрос относительно легко.График — это способ представления информации, поэтомуДиаграмма архитектуры, то есть диаграмма, выражающая «архитектуру», то есть способ выражения архитектуры.. Это:Диаграмма архитектуры = представление архитектуры = диаграмма, представляющая архитектуру.

Таким образом, мы должны ответить:

Что такое схема? Что такое выразить?
Как нарисовать архитектурную схему?

Следующее содержание в основном основано на этих двух измерениях для проведения анализа.

Что такое схема? Что такое выразить?

У Linus '03 есть хорошее описание, когда речь идет о разделении и интеграции:

Я утверждаю, что вы хотите начать общение между независимыми модулями не раньше, чем вы абсолютно ДОЛЖНЫ это сделать, и что вам следует избегать разделения вещей до тех пор, пока вам это действительно не понадобится, потому что сложность связи часто затмевает сложность реальных частей, участвующих в ней. Признаем явление, положимсложная системаРазделить на модули, кажется, не уменьшаетцелая системасложность. только понижаетподсистемасложность. Однако усложнение всей системы придется выполнять из-за разделяемых модулей.взаимодействовать, становится более сложным. )

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

Определение в Википедии:

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

Определение в Википедии:

**Architecture **is both the process and the product of planning, designing, and constructing buildings or any other structures.

Архитектура определена в ISO/IEC 42010:20072 следующим образом:

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

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

1. Сущность архитектуры

Вот три точки зрения на изучение природы архитектуры:

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

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

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

2. Что вы хотите выразить?

В области архитектуры EA есть два общих метода архитектуры RUP и TOGAF, эти две структуры также являются двумя измерениями классификации архитектуры, которые мы часто понимаем. Лично я считаю, что метод классификации TOGAF используется более широко (внизу справа).

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

3. Процесс архитектуры на самом деле является процессом моделирования

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

Определение энциклопедии Baidu:

моделированиеМоделирование, это своего рода действие с вещами, чтобы понять ихАннотация, является недвусмысленным письменным описанием чего-либо.

«Мышление в UML» определяет:

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

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

4. Что такое плесень? Как построить?

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

1) Бизнес-моделирование

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

Изображение взято из Интернета, это схематическая диаграмма, она навязчива и удалена.

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

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

Прочтите книгу толстым слоем:

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

Этот процесс будет очень скучным, особенно когда речь идет о какой-то деловой терминологии, которую будет сложно понять. Я думаю о себе как об «исследователе», точно так же, как когда мы играем в игры, я часто спрашиваю себя: «Моя игровая карта вся освещена?» Нет необходимости заботиться обо всех деталях, но необходимо стремиться охватить общее содержание. Если хорошенько подумать, то это похоже на ежедневное чтение.В этот период стоит отметить, что:

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

Прочтите книгу тонко:

В настоящее время основное внимание уделяется установлению «общей картины» и попытке разобраться в основной логической линии.Условно она будет разделена на горизонтальные и вертикальные или матричные рамки.Конечно, это должно быть основано на раннее понимание и анализ.**Здесь часто подразумевается одно из самых важных предположений: система должна использоваться людьми, и она должна решать проблемы клиентов, иначе она не имеет смысла существовать. Итак, основная процедура: кто? Какие сервисы/функции/возможности используются? Какую проблему он решает? Таким образом, мы можем описать: роли участников, возможности системы и интерактивные отношения.Что вам нужно спросить себя: какова граница? Что такое вход и выход? **Постепенно разбирать бизнес-функции по вариантам использования, формировать роли->основной процесс->отраслевые процессы, а затем формировать окончательное абстрактное бизнес-описание «картину» посредством непрерывной индукции и дедукции.

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

Логическое сравнение:

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

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

2) Моделирование системы

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

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

Изображение взято из Интернета, это схематическая диаграмма, она навязчива и удалена.

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

«Луковая чистка» от большого к меньшему, от грубого к мелкому, охватывающая все известные и возможные будущие бизнес-сценарии; хорошо использует различные модели для выражения: естественный язык, реляционные модели, диаграммы последовательности, диаграммы состояний, блок-схемы, различные представления моделей, такие как диаграммы иерархической архитектуры, полностью отображающие различные бизнес-сценарии и постоянно проверяемые;
Извлечение основных объектов: овладейте основными понятиями и основными отношениями, чтобы завершить создание основной модели;
Абсолютное оружие: все неоднозначные моменты дизайна/логики, вынести все известные сцены отдельно и рассказать их про себя.

«Очистить луковицу»:

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

Извлечение основного объекта:

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

метод объектного анализа

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

Понимание этой концепции в основном согласуется с нашим объектно-ориентированным пониманием всех вещей и объектов. Поэтому извлечению сущностей также можно научиться методом объектного анализа: независимого, абстрактного, иерархического и атомарного на одном уровне. На следующем рисунке показан метод анализа объектов в «Мышлении в UML».

метод анализа вариантов использования

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

В полном описании варианта использования, во-первых, ищите существительные, в основном «субъект» и «объект», эти существительные могут в основном определять нашу сущность; во-вторых, ищите прилагательные, которые существуют в «атрибутивных» и «наречных», и нахождение прилагательных может в основном использоваться.Определить значение соответствующего атрибута, затем, дополняя вариант использования, уточняя, исправляяимя существительноеОпределите, и постепенно мы получим нашу модель предметной области и соответствующие свойства. Наконец, отношения между ними определяются глаголами и прилагательными (существующими в [сказуемое], [наречие], [атрибутив]).

метод анализа проблемы

Это метод, упомянутый в «Архитектуре чата». В частности, он заключается в том, чтобы найти предмет проблемы, затем проанализировать жизненный цикл субъекта, а затем сосредоточиться на ключевых атрибутах и ключевых отношениях субъекта, выделяя ключевые действия в жизненный цикл. Рекомендуется прочитать первые 9 глав, всего 40 страниц, и у вас может быть некоторый опыт. Вот пример из книги:

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

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

Абсолютное оружие — поговорите с собой:

В реальном развитии бизнеса бизнес-дизайн и реализация часто должны удовлетворять бизнес-сценариям верхнего уровня N, которые имеют общие черты и индивидуальные требования.В этом процессе нас легко сбить с толку сходством и различием между несколькими сценариями, или логика неясно, либо переработано, либо необдуманно. Я заметил, что многие одноклассники, в том числе и я, склонны терять фокус на дизайне, когда бизнес сложный. Мой подход похож на бизнес-моделирование, но его необходимо логически сопоставить: во всех проектно-логических неоднозначных точках поставить все известные сценариивложены отдельно, говорите сами с собой. Обратите внимание, что это «отдельно вложенные».После проверки следующей сцены в текущем уровне дизайна, проверяется следующая сцена, и находятся заблокированные и нечеткие точки, а дизайн реорганизуется и оптимизируется. Результаты системного моделирования направляют наше проектирование и реализацию программного обеспечения, поэтому его необходимо многократно перебирать, Этот повторяющийся процесс на самом деле является процессом улучшения возможностей архитектуры, и он, естественно, будет прозрачным при накоплении в определенной степени.

Вернемся к вопросу в начале:

**Что такое плесень? **Судя по приведенному выше описанию бизнес-моделирования и системного моделирования, проще говоря, модель — это бизнес-отображение.Результатом этого отображения является бизнес-модель, концептуальная модель или проектная модель, но все отправные точки — это бизнес-требования: кто заказчик? Каковы основные требования?

**Как построить? **Через два аспекта бизнес-моделирования и системного моделирования обычные рутинные действия грубо описываются с точки зрения личной практики.Суть моделирования на самом деле является абстрактным процессом, но на самом деле для вышеупомянутого бизнеса есть еще два абстрактных процесса. и системное моделирование.Вопрос не совсем ясен:

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

вернуться к абстракции

Пол Худак, один из разработчиков языка Haskell, однажды сказал несколько преувеличенное утверждение: три самые важные вещи в программировании:абстрактный, абстрактный, абстрактный.

**"abstraction, abstraction, abstraction"**are the three most important things in programming.

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

Определение энциклопедии Baidu:

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

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

1. Абстрактная перспектива

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

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

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

Абстрактная перспектива на самом деле является классификационной перспективой Различные точки зрения приведут к совершенно разным направлениям моделирования и результатам;
Абстрактная перспектива – это направление и цель моделирования («приклад определяет голову»).

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

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

2. Уровни абстракции

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

Мой выпуск San Francisco Chronicle от 18 мая.

Хроника Сан-Франциско, 18 мая.

Хроника Сан-Франциско

газета

публикация

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

Итак, что является основой для уровня абстракции здесь? Каков принцип? Мой опыт,Основание деления уровня абстракцииИх в основном два:

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

На самом деле это не совсем объясняет, как наслаивать, в чем принцип? я думаю это несколькосамые общие принципы:

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

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

3. Абстрактные границы

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

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

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

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

项目管理->场馆座位分销->票房预测->场次管理->配额管理->绘座->票房规划

С точки зрения производства основным объектом является не билет, а количество раз (представление или событие, определяющее время, место и содержание). быть рассмотрены в области производства.Главным является основной жизненный цикл сеанса.

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

4. Абстрактная оценка

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

Связь — это мера взаимосвязи между модулями в структуре программного обеспечения; · Сплоченность – это мера степени корреляции между компонентами внутри модуля.

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

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

5. Абстрактная методология (рутина)

Я думаю, что на данный момент мы прояснили предыдущие два вопроса:

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

Суммируйте все содержание упомянутой выше абстракции, сформируйтеАбстрактная методология (рутинная):

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

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

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

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

Итак, для чего нужна архитектурная диаграмма? Кого посмотреть? Чтобы ответить на этот вопрос, нам нужно уточнить, зачем нам рисовать архитектурные схемы, при этом также необходимо рассмотреть вопрос: чем больше архитектурных диаграмм, тем лучше, а чем подробнее — тем лучше?

1. Какова цель построения схемы архитектуры?

Картинка стоит тысячи слов (картинка стоит тысячи слов), на уровне «почему» я думаю, что это следующие два пункта:

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

Но приведенные выше два пункта на самом деле являются очень общей информацией.Если мы поместим это на уровень Что, мы должны рассмотреть «клиентов», с которыми сталкивается диаграмма архитектуры.Разные клиенты имеют разные требования (фактически, углы и уровни), и в разных абстракции Информационное содержание, представляемое диаграммой иерархии, может быть совершенно разным. Взяв за пример то, что делает текущая команда, целевые клиенты диаграммы архитектуры имеют как минимум несколько категорий:

Роли каждой команды, участвующей в проекте (бизнес, продукт, разработка, тестирование, безопасность, GOC)
Клиенты вне проекта (внешние клиенты, внешние эксперты по обзору)
TL на всех уровнях (отчетность, кросс-BU, совместная работа и общение между командами)

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

2. Как рисовать?

1) Давайте сначала поговорим о классификации

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

С точки зрения разработки бизнес-приложений общие уровни абстракции можно разделить на:

业务全域—>子域—>模块—>子模块—>包—>类—>方法

некоторые из:

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

Конечно, существует множество других методов классификации, таких как: RUP 4+1, GOGAF9 и так далее. **С практической точки зрения, я думаю, что классификация не самое главное, главное разобраться, с кем столкнуться и какие требования решать, а потом подумать, с какого ракурса и уровня абстрагировать архитектурную схему. . **Для проектов, над которыми мы сейчас работаем, иногда приходится общаться с зарубежными бизнес-экспертами и техническими экспертами.У нас нет четкого стандартного определения.Важнее всего четко сформулировать проблему и прийти к консенсусу.Что касается Структура Детализация, категория и содержание графика могут быть постепенно улучшены, грубы и уточнены, а также итеративно оптимизированы.

2) Поговорим о композиции

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

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

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

3. Как оценить хорошую или плохую архитектурную диаграмму

Я понимаю качество диаграммы архитектуры в основном в двух направлениях. Один - смотреть за рамки самой диаграммы. Рациональность абстрактного дизайна бизнес-поля и независимо от того, соответствует ли он требованиям «высокой сплоченности и низкой связи». Это должно Вернитесь к предыдущей статье. Бизнес-моделирование, системное моделирование и процессы абстракции, чтобы найти ответы. Другим направлением является сам граф, следующие точки для справки:

Терминология контента постоянна, детализированность информации постоянна, легенда понятна, цветотип однороден, и это красиво;
Информация на графе относится к соответствующему уровню абстракции и отвечает потребностям стейкхолдеров (партнеров);
Хорошая архитектурная схема не нуждается в избыточных текстовых пояснениях! Получает ли аудитория именно то, что хочет донести, если это вызывает больше вопросов, чем может объяснить, значит, это нехорошая архитектурная схема;
Диаграммы архитектуры должны помочь каждому увидеть общую картину, понять окружающую среду, соответствующую контекстуальную информацию;
Диаграммы архитектуры не должны «видеть деревья, но не лес».

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

Наконец, давайте поговорим об архитекторе

Это из статьи Учителя А Бай «Что делает архитектор? ", чем больше я думаю об этом, тем больше я это чувствую. Среди них упоминаются портреты хороших архитекторов и плохие портреты, как показано на рисунке ниже, чтобы поделиться с вами.

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

1. Учитесь быстро

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

2. Не позволяйте заднице решать вашу голову

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

3. Улучшить мыслительные способности и понимание принципа или сути технологии

Я думаю, что это возможности нижнего уровня, и я думаю, что две самые большие трудности в развитии бизнеса: одна — сложность логики, а другая — изменчивость требований. Вместо того, чтобы тратить большую часть нашего времени на поиск решений, мы должны тратить больше времени на их выбор. Это требует от нас формирования собственного понимания общей ситуации в бизнесе, глубины отрасли, технического видения, технической глубины, общности бизнеса, личностных характеристик и т. д. Компромиссы, что выбрать? Как выбрать, как выбрать? Где эта степень? Только думающие, самостоятельные, накапливающие и настойчивые, смелые и прилежные, и неустанно работающие добровольцами.

последний из последних

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

Справочная документация:

Почему нам нужны архитектурные диаграммы (new.QQ.com/О, красота/2019013…)
Искусство диаграмм архитектуры программного обеспечения (Woohoo.info Q. талант/статья/позор...)
Логическая архитектура и физическая архитектура (Блог Woohoo.cn на.com/dinglang/afraid/…)
Статья для понимания многоуровневой архитектуры (zhuanlan.zhihu.com/p/40353581)
TOGAF & RUP(Woohoo. IBM.com/developer Я…)
Как вывести архитектуру логики приложения снизу вверх? + Как строить архитектуру сверху вниз? (отрывок)(developer.aliyun.com/article/727…)
Слон: мышление в UML
«Архитектура чата»

Подпишитесь на официальный аккаунт «Alibaba Cloud Native» и ответьте на «Архитектура», чтобы увидеть четкую общую картину знаний!

Как нарисовать архитектурную схему? (Включает диаграмму знаний)