Глубокое погружение в стили и разделение структуры в архитектуре программного обеспечения

12 апреля 2023 г.

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

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

Архитектуры программного обеспечения

Консультационная компания, в которой я работал, определила две основные определенные практики или действия, которым необходимо следовать при запуске проекта с клиентом, а именно: открытие и начало. В этих мероприятиях участвовало несколько членов команды с разными ролями, такими как BA, XD, PM, QA, Dev и инженеры по инфраструктуре, с целью сопоставления всех требований и точек зрения с коммерческой и технической стороны.

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

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

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

Архитектурные стили

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

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

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

Некоторые примеры распространенных архитектурных стилей:

1. Многоуровневый
2. Сервисно-ориентированная архитектура (SOA)
3. Модульный монолит
4. Микроядро
5. Архитектура, управляемая событиями (EDA)
6. Микросервисы

Разделение структуры архитектуры

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

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

Разделение структуры архитектуры программного обеспечения

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

Разделение структуры: техническое

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

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

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

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

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

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

Разделение структуры: домен

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

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

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

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

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

Архитектурный стиль и примеры использования разделения структуры

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

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

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

3. Платформа уведомлений. Платформа уведомлений обычно характеризуется необходимостью обрабатывать и реагировать на различные асинхронные события, такие как действия пользователя, изменения состояния системы или внешние триггеры. Хорошо подходит архитектура, управляемая событиями, поскольку она обеспечивает асинхронную связь между компонентами, что позволяет эффективно обрабатывать большое количество событий и уведомлений. Архитектура микросервисов (разделение структуры домена) может использоваться для управления многочисленными функциями службы уведомлений, такими как маршрутизация сообщений, управление пользователями, доставка сообщений и аналитика.< /p>

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

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

Пример системы TODO

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

Для разработки системы TODO мы должны выполнить следующие требования:

* Он предоставит пользовательский интерфейс, который будет отображаться в браузере с адаптивным дизайном, подходящим как для настольных компьютеров, так и для мобильных устройств. * Это позволит выполнять следующие операции: список, создание, редактирование и удаление. * Статус TODO будет следующим: todo, in-progress, block и done. * Информация будет сохранена в реляционной базе данных. * Основные компоненты будут содержать автоматические тесты, которые будут запускаться в конвейере каждый раз, когда в репозиторий вносятся изменения.

Выбор стиля архитектуры программного обеспечения

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

Сервисно-ориентированная архитектура (SOA)

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

Архитектура, управляемая событиями

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

Микроядро

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

Микросервисы

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

Модульная монолитная

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

Многослойный

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

Результат компромисса

При сравнении стилей архитектур, таких как многоуровневая архитектура, SOA, EDA, микроядро и микросервисы, многоуровневая архитектура обеспечивает более простой и понятный подход, который хорошо соответствует требованиям базовой системы TODO (пользовательский интерфейс, серверная часть и база данных). Хотя SOA, EDA и микросервисы больше подходят для сложных, распределенных и хорошо масштабируемых систем, они вносят дополнительную сложность и накладные расходы, которые могут не понадобиться для простой системы TODO. Архитектура микроядра, с другой стороны, больше подходит для систем с базовой функциональностью, которую можно расширить с помощью плагинов, что не является основным требованием для системы TODO. Сравнивая многоуровневую архитектуру с модульной монолитной архитектурой, оба подхода предлагают модульность, удобство сопровождения и четкую организацию. Однако многоуровневая архитектура обеспечивает более явное разделение задач, разделяя систему на отдельные уровни, отвечающие за пользовательский интерфейс, внутреннюю службу и взаимодействие с базой данных. Такое разделение упрощает разработку, тестирование и обслуживание, а также облегчает дальнейшее развитие системы. В результате многоуровневая архитектура является более подходящим выбором для системы TODO, поскольку она обеспечивает правильный баланс между простотой, удобством сопровождения и простотой разработки, обеспечивая при этом требуемую функциональность.

Выбор разделов структуры архитектуры программного обеспечения

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

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

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

1. Презентационный уровень:
2. Этот уровень будет отвечать за отрисовку пользовательского интерфейса (UI) в браузере, обработку взаимодействия с пользователем и представление данных пользователю.
3. Технологии. Для создания пользовательского интерфейса можно использовать HTML, CSS, JavaScript и интерфейсную среду, такую ​​как Next, React, Angular или Vue.js.
4. Бизнес-уровень:
5. Этот уровень будет содержать бизнес-логику для системы TODO, обрабатывать запросы пользователей и координировать взаимодействие между уровнями представления и сохранения.
6. Технологии. Для реализации бизнес-уровня можно использовать серверную платформу, такую ​​как Express.js (Node.js), Flask (Python) или Spring Boot (Java).
7. Уровень сохраняемости:
8. Этот уровень будет отвечать за связь с реляционной базой данных PostgreSQL для хранения, извлечения и управления данными TODO.

9. Технологии. Для взаимодействия с базой данных PostgreSQL можно использовать библиотеку объектно-реляционного сопоставления (ORM), такую ​​как Sequelize (Node.js), SQLAlchemy (Python) или Hibernate (Java).< /p>

Возможности системы TODO будут реализованы следующим образом:

* Список: бизнес-уровень извлекает список TODO из уровня сохраняемости и отправляет данные на уровень представления для отображения. * Создание: уровень представления фиксирует ввод пользователя и отправляет запрос на уровень бизнеса, который проверяет ввод и вызывает уровень сохраняемости для сохранения нового TODO в базе данных PostgreSQL. * Редактировать: уровень представления отправляет запрос на обновление на бизнес-уровень с измененными данными TODO, который затем обновляет соответствующую запись в базе данных с помощью уровня сохраняемости. * Удалить: уровень представления отправляет запрос на удаление бизнес-уровню, который затем удаляет соответствующую запись из базы данных с помощью уровня сохраняемости.

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

Вы можете найти пример реализации кода по следующим ссылкам:

* Веб-приложение Nextjs TODO: https://github.com/herrera-luis. /layered-next-todo-service * Flask TODO API: https://github.com/herrera-luis/ многоуровневая-фляга-todo-сервис

Схемы архитектуры программного обеспечения

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

По моему опыту, модель C4 популярна и широко используется архитекторами программного обеспечения для подробного построения диаграмм архитектуры программного обеспечения, поскольку она включает в себя несколько уровней абстракции, включая уровень 1 — системный контекст, уровень 2 — контейнер, уровень 3 — компонент и уровень 4 — код. . Большинство клиентов обычно создают диаграммы до уровня 3, который является диаграммой компонентов, поскольку он хорош для долгоживущей документации, а аудиторией являются архитекторы и разработчики. Уровень 4 считается необязательным, так как он предоставляет краткосрочную документацию, которая может автоматически создаваться интегрированными средами разработки (IDE).

Для нашей системы TODO мы собираемся создать диаграммы C4, но только до уровня 3, поскольку код не готов к работе и должен быть приспособлен или просто использован в качестве справочного примера, что означает, что уровень 4 очень восприимчив к изменениям.

Уровень 1: Диаграмма контекста системы

Контекстная диаграмма уровня 1 в модели C4 обеспечивает высокоуровневое представление всей системы, иллюстрируя ее взаимодействие с клиентами и внешними системами. В нашей системе TODO мы не интегрируем внешние системы, такие как методы аутентификации или уведомления, поэтому нашим основным контекстом на этом уровне будут система и клиент.

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

Уровень 2: диаграмма контейнера

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

* Веб-приложение (пользовательский интерфейс): включите веб-приложение, которое служит пользовательским интерфейсом для взаимодействия с приложением API. Этот контейнер управляет входными данными клиентов, отображает задачи и взаимодействует с серверными службами. * App API: этот контейнер отвечает за обработку запросов клиентов, управление задачами и взаимодействие с уровнем хранения данных. * База данных: система хранения данных используется для хранения данных TODO

Уровень 3: Диаграмма компонентов

В системе TODO диаграмма компонентов уровня 3 фокусируется на внутренней структуре и взаимодействии основных компонентов внутри системы, поэтому она состоит из следующих частей.

Веб-приложение (пользовательский интерфейс):

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

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

* Компоненты: реализуйте многократно используемые элементы пользовательского интерфейса и управляйте связанной логикой, такой как пользовательский ввод, отображение данных и взаимодействия. Примеры: ConfirmationModal.tsx, ErrorBoundary.tsx, TodoForm.tsx, TodoItem.tsx, TodoList.tsx.

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

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

Приложение API

В этом контейнере конечные точки API обрабатывают входящие HTTP-запросы и предоставляют службы RESTful для управления задачами. Он состоит из следующих частей:

* Компонент маршрутов: этот компонент управляет маршрутами API приложения API, предоставляя интерфейс для взаимодействия клиентских приложений с системой. Он определяет методы HTTP (например, GET, POST, PUT, DELETE) и соответствующие URL-адреса для различных операций, таких как создание, обновление, удаление или получение TODO. Компонент Routes обрабатывает входящие запросы, направляя их компонентам службы в приложении для дальнейшей обработки. Это также гарантирует отправку клиенту надлежащих ответов, содержащих необходимые данные или коды состояния.

* Компонент службы: отвечает за основные функции приложения API, этот компонент управляет созданием, изменением, удалением и завершением TODO. Он также обрабатывает любую бизнес-логику или правила, связанные с задачами.

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

* Компонент базы данных: отвечает за сохранение TODO и связанных с ними данных, гарантируя, что информация хранится и извлекается из источника данных (например, базы данных или хранилища в памяти, такого как sqlite) по мере необходимости.

Бонус: шестиугольная архитектура

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

Многоуровневая архитектура

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

Микросервисы

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

Архитектура, управляемая событиями

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

Модульный монолит

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

Микроядро

Архитектура микроядра объединяет компоненты в базовую систему (микроядро) и набор подключаемых модулей или расширений. Сочетание микроядерной архитектуры с гексагональной архитектурой позволяет четко разделить базовую функциональность и особенности предметной области. В этом подходе микроядро управляет центральной функциональностью, а плагины или расширения реализуют дополнительные функции, используя гексагональную архитектуру. Например, в CMS микроядро может обрабатывать базовое хранение и поиск контента, а плагины для различных форматов контента, таких как изображения, видео и документы, разрабатываются с использованием гексагональной архитектуры. Каждый подключаемый модуль имеет порты ввода и вывода для связи с микроядром и внешними системами, а адаптеры преобразуют данные или запросы между микроядром, внешними системами и подключаемыми модулями.

Заключение

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

---

Также опубликовано здесь

---

Оригинал