Это вводное руководство для архитекторов программного обеспечения. В настоящее время звание «архитектор» очень популярно во всем мире, но не существует настоящего руководства, как стать архитектором программного обеспечения.
1. Общая концепция архитектуры программного обеспечения
2. Архитектурные стили
3. Технология
4. Софт скиллз (принятие архитектурных решений, методы анализа рисков, навыки подачи материала, отношения с командой менеджеров, ведение переговоров, планирование карьеры архитектора)
5. Принципы проектирования
В реальном мире не существует одного определенного решения для конкретной проблемы. Когда мы изучаем архитектурные дисциплины в теории или на практике, мы должны понимать, что многие архитектурны решения принимаются, исходя из реальной ситуации.
Архитектурные стили – это типология архитектурных подходов, реализуемых в системе, например, микросервисы, иерархические подходы или микроядра. Ниже показаны несколько примеров:
Архитектурные решения определяют правила построения системы. Например, архитектор может решить, что только бизнес-уровень и сервисный уровень могут обращаться к базе данных, и ограничить уровень представления от прямого обращения к базе данных. Архитектурные решения формируют ограничения системы и помогают разработчикам сориентироваться, что разрешено, а что нет.
Принципы проектирования — это руководство, а не жёсткие правила. Принципы проектирования служат лишь указаниями по предпочтительному методу, поскольку архитектурное решение никогда не может охватить все условия и варианты связи между сервисами (позволяют разработчикам выбрать более подходящий протокол связи в конкретной ситуации (например, REST или gRPC).
Принципы проектирования: меньшее зацепление, высокая связность, локальность, устранимость, модульность и небольшие компоненты.
Подробнее здесь.
Принципы связности компонентов таковы:
• REP: Принцип эквивалентности повторного использования/выпуска
• CCP: Общий принцип закрытия
• CRP: Общий принцип повторного использования
1. Сохраняйте конфигурируемые данные на высоком уровне
2. Предпочитайте полиморфизм вместо If/else или switch/case
3. Не будьте непоследовательными
4. Разделяйте многопоточный код
5. Только 1 уровень абстракции на уровне
6. Поля не определяют состояние
7. Микрослои
8. Синглтоны / локатор сервисов
9. Базовые классы в зависимости от их производных
10. Завистливые функции
11. Неиспользуемое зацепление
12. Скрытое зацепление
13. Переходная навигация
• Относиться к взгляду на вещи с архитектурной позиции и точки зрения,
• Понимать разницу между архитектурой программного обеспечения и проектированием программного обеспечения, знать, как работать с командой разработчиков.
• Обладать техническим кругозором, поддерживать определенную техническую углубленность и видеть решения и возможности, которые не видят другие.
• Понимать, анализировать и согласовывать компромиссы между различными решениями и технологиями
• Понимать важность бизнес-требований и то, как перевести их в архитектуру.
• Архитектор анализирует бизнес-требования, извлекает и определяет архитектурные особенности, выбирает архитектурные стили, создает компоненты, а затем передает их команде разработчиков. Команда разработчиков создает классы и пользовательские интерфейсы для каждого компонента и тестирует исходный код.
В начале карьеры разработчика основное внимание уделяется расширению вершины пирамиды, накоплению опыта и знаний.
Архитекторы должны обладать широким техническим кругозором, чтобы осмыслить проблему.
• Серый уровень: технологии, фреймворки, языки и инструменты, используемые в повседневной работе
• Жёлтый уровень: то, что вы немного знаете, но не обладаете глубокими профессиональными знаниями.
• Красный уровень: «слепое пятно» каждого архитектора
Для хорошего разработчика наиболее важна верхняя треть.
Для архитекторов разумно пожертвовать некоторыми приобретенными знаниями и использовать это время для расширения кругозора. Это тоже компромисс.
Разработчики на протяжении всей карьеры оттачивают опыт, и переход на роль архитектора означает пересмотр приоритетов. Это сложно для многих людей и часто приводит к двум проблемам:
• Попытка сохранить профессионализм в каждой области, что приводит к неудачной работе в любой области, и выполнение работы очень грубо;
• Непонимание того, что свои устаревшие знания все еще являются передовыми, что часто встречается в крупных компаниях.
Разработчики, переходящие на роль архитектора, должны изменить свой взгляд на приобретение знаний. Баланс между глубиной и широтой знаний — это вопрос, который каждый разработчик должен рассматривать на протяжении всей своей карьеры.
В роли архитектора широта знаний важнее глубины. Потому что архитекторы должны принимать решения на основе тех идей, которые есть у них в голове.
Архитектура — это то, что вы не можете загуглить. Все в архитектуре — это компромисс.
• Потому что это действительно зависит от среды развертывания, бизнеса, культуры компании, бюджета, времени, квалификации разработчика и десятков других факторов.
• В архитектуре нет правильного или неправильного ответа, все может быть компромиссом.
Например, рассмотрим аукционную систему с двумя режимами потребления данных, именуемыми «публикация» и «подписка».
• Если мы хотим добавить новую службу «история торгов», нам не нужно вносить никаких изменений в существующую систему; а в модели очереди нам может понадобиться модифицировать производителя, чтобы добавить очередь.
• Уменьшение зацепления: производителю не нужно знать, какие сервисы используются и как использовать данные; в модели очереди производителю нужно знать, какого типа данные и кому.
• Мышление архитектора должно подсказывать преимущества и недостатки решения.
• Любой может получить доступ к данным модели «публикация-подписка», при этом возникают вопросы доступа к данным и безопасности.
• Модель «публикация-подписка» может принимать данные только в одном и том же формате. Предполагается, что для новой службы «история торгов» требуется текущая цена продажи и торги, но другие службы изначально не имеют этой информации. В этом случае необходимо изменить формат данных, что отразится на пользователе. Все остальные сервисы данных. В модели очереди это будет отдельный канал и, следовательно, отдельный формат, не затрагивающий другие сервисы.
• Модель «публикация-подписка» не поддерживает мониторинг количества сообщений в теме, что приводит к отсутствию поддержки автоматического масштабирования. Легко узнать, в какой очереди находится большое количество сообщений, и ее можно автоматически масштабировать самостоятельно. Обратите внимание, что этот компромисс зависит от конкретной технологии, и Advanced Message Queuing Protocol (AMQP) может поддерживать балансировку нагрузки и мониторинг.
Архитектура программного обеспечения состоит из требований и всех других архитектурных особенностей.
Список архитектурных характеристик (неполный)
Характеристики операционной архитектуры в значительной степени пересекаются с проблемами операций и DevOps, образуя точку пересечения этих проблем во многих программных проектах.
Подробнее по теме предлагаем вам ознакомиться со следующими книгами:
Фундаментальный подход к программной архитектуре:
паттерны, свойства, проверенные методы
Марк Ричардс, Нил Форд
» Оглавление
» Отрывок
⠀
Современный подход к программной архитектуре: сложные компромиссы
Нил Форд, Марк Ричардс, Прамод Садаладж, Жамак Дехгани
» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — Заметки
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
P.S.
Также обращаем ваше внимание на то, что у нас на сайте проходит распродажа.
1. Общая концепция архитектуры программного обеспечения
2. Архитектурные стили
3. Технология
4. Софт скиллз (принятие архитектурных решений, методы анализа рисков, навыки подачи материала, отношения с командой менеджеров, ведение переговоров, планирование карьеры архитектора)
5. Принципы проектирования
В реальном мире не существует одного определенного решения для конкретной проблемы. Когда мы изучаем архитектурные дисциплины в теории или на практике, мы должны понимать, что многие архитектурны решения принимаются, исходя из реальной ситуации.
Архитектурные стили – это типология архитектурных подходов, реализуемых в системе, например, микросервисы, иерархические подходы или микроядра. Ниже показаны несколько примеров:
Архитектурные решения определяют правила построения системы. Например, архитектор может решить, что только бизнес-уровень и сервисный уровень могут обращаться к базе данных, и ограничить уровень представления от прямого обращения к базе данных. Архитектурные решения формируют ограничения системы и помогают разработчикам сориентироваться, что разрешено, а что нет.
Принципы проектирования — это руководство, а не жёсткие правила. Принципы проектирования служат лишь указаниями по предпочтительному методу, поскольку архитектурное решение никогда не может охватить все условия и варианты связи между сервисами (позволяют разработчикам выбрать более подходящий протокол связи в конкретной ситуации (например, REST или gRPC).
Принципы проектирования: меньшее зацепление, высокая связность, локальность, устранимость, модульность и небольшие компоненты.
Принципы SOLID
| S | Принцип единственной ответственности | Для каждого объекта должно быть определено единственное назначение и это должно быть инкапсулировано классом |
| O | Принцип открытости/закрытости | Программное обеспечение должно быть открыто для расширения, но закрыто для модификации |
| L | Принцип подстановки Лисков | Любой подкласс всегда должен использоваться вместо своего родительского класса |
| I | Принцип разделения интерфейса | Много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения |
| D | Принцип инверсии зависимостей | Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций |
Принцип проектирования: класс проектирования
| Принцип единственной ответственности (SRP) | Для изменения класса должно быть более одной причины |
| Принцип открытости/закрытости (OCP) | Программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации |
| Принцип подстановки Лисков (LCP) | Указатели ссылок на базовые классы должны иметь возможность использовать объекты производных классов, не зная об этом |
| Принцип разделения интерфейса (ISP) | Много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения |
| Принцип инверсии зависимостей (DIP) | Зависимость от абстракций, а не от конкретики |
Принципы чистой архитектуры от Боба Мартина
Подробнее здесь.
Принцип проектирования: Связность
Принципы связности компонентов таковы:
• REP: Принцип эквивалентности повторного использования/выпуска
• CCP: Общий принцип закрытия
• CRP: Общий принцип повторного использования
Принципы упаковки
| Принципы связи пакетов | Принципы сцепления пакетов |
| Принцип эквивалентности повторного использования-релиза (REP) • REP по существу означает, что пакет должен быть создан с многократно используемыми классами |
Принцип ациклических зависимостей (ADP) • ADP утверждает, что в структуре зависимостей не может быть циклов, и что когда выпускается инкрементный релиз, другие разработчики могут перенимать его и строить на его основе |
| Принцип общего повторного использования (CRP) • CRP утверждает, что классы, которые обычно используются повторно вместе, должны находиться в одном пакете вместе |
Принцип стабильных зависимостей (SDP) • SDP утверждает, что любые пакеты, которые хочется сделать изменчивыми, не должны зависеть от пакета, который трудно изменить |
| Общий принцип закрытия (CCP) • CCP утверждает, что пакет не должен иметь более одной причины для изменения |
Принцип стабильных абстракций (SAP) • SAP утверждает, что стабильный пакет также должен быть абстрактным, чтобы его стабильность не препятствовала его расширению |
Высокоуровневая архитектура
1. Сохраняйте конфигурируемые данные на высоком уровне
2. Предпочитайте полиморфизм вместо If/else или switch/case
3. Не будьте непоследовательными
4. Разделяйте многопоточный код
5. Только 1 уровень абстракции на уровне
6. Поля не определяют состояние
7. Микрослои
8. Синглтоны / локатор сервисов
9. Базовые классы в зависимости от их производных
10. Завистливые функции
11. Неиспользуемое зацепление
12. Скрытое зацепление
13. Переходная навигация
Архитектурное мышление
• Относиться к взгляду на вещи с архитектурной позиции и точки зрения,
• Понимать разницу между архитектурой программного обеспечения и проектированием программного обеспечения, знать, как работать с командой разработчиков.
• Обладать техническим кругозором, поддерживать определенную техническую углубленность и видеть решения и возможности, которые не видят другие.
• Понимать, анализировать и согласовывать компромиссы между различными решениями и технологиями
• Понимать важность бизнес-требований и то, как перевести их в архитектуру.
• Архитектор анализирует бизнес-требования, извлекает и определяет архитектурные особенности, выбирает архитектурные стили, создает компоненты, а затем передает их команде разработчиков. Команда разработчиков создает классы и пользовательские интерфейсы для каждого компонента и тестирует исходный код.
Традиционный взгляд на архитектуру в сравнении с проектированием
В начале карьеры разработчика основное внимание уделяется расширению вершины пирамиды, накоплению опыта и знаний.
Архитекторы должны обладать широким техническим кругозором, чтобы осмыслить проблему.
• Серый уровень: технологии, фреймворки, языки и инструменты, используемые в повседневной работе
• Жёлтый уровень: то, что вы немного знаете, но не обладаете глубокими профессиональными знаниями.
• Красный уровень: «слепое пятно» каждого архитектора
Для хорошего разработчика наиболее важна верхняя треть.
Для архитекторов разумно пожертвовать некоторыми приобретенными знаниями и использовать это время для расширения кругозора. Это тоже компромисс.
Разработчики на протяжении всей карьеры оттачивают опыт, и переход на роль архитектора означает пересмотр приоритетов. Это сложно для многих людей и часто приводит к двум проблемам:
• Попытка сохранить профессионализм в каждой области, что приводит к неудачной работе в любой области, и выполнение работы очень грубо;
• Непонимание того, что свои устаревшие знания все еще являются передовыми, что часто встречается в крупных компаниях.
Разработчики, переходящие на роль архитектора, должны изменить свой взгляд на приобретение знаний. Баланс между глубиной и широтой знаний — это вопрос, который каждый разработчик должен рассматривать на протяжении всей своей карьеры.
В роли архитектора широта знаний важнее глубины. Потому что архитекторы должны принимать решения на основе тех идей, которые есть у них в голове.
Архитектура — это то, что вы не можете загуглить. Все в архитектуре — это компромисс.
• Потому что это действительно зависит от среды развертывания, бизнеса, культуры компании, бюджета, времени, квалификации разработчика и десятков других факторов.
• В архитектуре нет правильного или неправильного ответа, все может быть компромиссом.
Например, рассмотрим аукционную систему с двумя режимами потребления данных, именуемыми «публикация» и «подписка».
Преимущества модели «публикация-подписка»
• Если мы хотим добавить новую службу «история торгов», нам не нужно вносить никаких изменений в существующую систему; а в модели очереди нам может понадобиться модифицировать производителя, чтобы добавить очередь.
• Уменьшение зацепления: производителю не нужно знать, какие сервисы используются и как использовать данные; в модели очереди производителю нужно знать, какого типа данные и кому.
• Мышление архитектора должно подсказывать преимущества и недостатки решения.
Преимущества модели с использованием очередей
• Любой может получить доступ к данным модели «публикация-подписка», при этом возникают вопросы доступа к данным и безопасности.
• Модель «публикация-подписка» может принимать данные только в одном и том же формате. Предполагается, что для новой службы «история торгов» требуется текущая цена продажи и торги, но другие службы изначально не имеют этой информации. В этом случае необходимо изменить формат данных, что отразится на пользователе. Все остальные сервисы данных. В модели очереди это будет отдельный канал и, следовательно, отдельный формат, не затрагивающий другие сервисы.
• Модель «публикация-подписка» не поддерживает мониторинг количества сообщений в теме, что приводит к отсутствию поддержки автоматического масштабирования. Легко узнать, в какой очереди находится большое количество сообщений, и ее можно автоматически масштабировать самостоятельно. Обратите внимание, что этот компромисс зависит от конкретной технологии, и Advanced Message Queuing Protocol (AMQP) может поддерживать балансировку нагрузки и мониторинг.
Инженерная практика
Архитектура программного обеспечения состоит из требований и всех других архитектурных особенностей.
Список архитектурных характеристик (неполный)
Характеристики операционной архитектуры
| Термин | Определение |
| Доступность | Как долго система должна быть доступна (если круглосуточно, то необходимо предусмотреть меры, позволяющие быстро восстановить работоспособность системы в случае любого сбоя). |
| Непрерывность | Возможность восстановления после сбоев. |
| Производительность | Включает стресс-тестирование, анализ пиковых нагрузок, анализ частоты использования функций, требуемой мощности и времени отклика. Приемка производительности иногда требует отдельного испытания, на которое уходят месяцы. |
| Восстанавливаемость | Требования к непрерывности бизнеса (например, в случае сбоя, как быстро система должна быть восстановлена?). Это повлияет на стратегию резервного копирования и требования к дублирующему оборудованию. |
| Надежность/безопасность | Оцените, должна ли система быть отказоустойчивой, или она критически важна, так как влияет на жизнь людей. Если она выйдет из строя, будет ли это стоить компании больших денег? |
| Устойчивость | Способность обрабатывать ошибки и предельные условия во время работы, если пропадает подключение к Интернету, отключается электричество или происходит отказ оборудования. |
| Масштабируемость | Способность системы работать и функционировать при увеличении числа пользователей или запросов. |
Характеристики структурной архитектуры
| Термин | Определение |
| Конфигурируемость | Возможность для конечных пользователей легко изменять аспекты конфигурации программного обеспечения (через удобные интерфейсы). |
| Расширяемость | Насколько важно подключать новые функциональные элементы. |
| Устанавливаемость | Лёгкость установки системы еа всех требуемых платформах. |
| Возможность применения/повторного использования | Способность использовать общие компоненты в нескольких продуктах. |
| Локализация | Поддержка нескольких языков на экранах ввода/запроса в полях данных; в отчетах, требования к многобайтовым символам и единицам измерения или валютам. |
| Ремонтопригодность | Насколько легко вносить изменения и совершенствовать систему? |
| Портативность | Должна ли система работать на нескольких платформах? (Например, должен ли фронтенд работать как на Oracle, так и на SAP DB? |
| Поддерживаемость | Какой уровень технической поддержки необходим приложению? Какой уровень протоколирования и другие средства необходимы для отладки ошибок в системе? |
| Возможность модернизации | Возможность легко/быстро перейти с предыдущей версии данного приложения/решения на более новую версию на серверах и клиентах. |
Сквозные характеристики архитектуры
| Термин | Определение |
| Доступность | Доступ для всех ваших пользователей, включая людей с ограниченными возможностями, такими как дальтонизм или потеря слуха. |
| Архивируемость | Нужно ли архивировать или удалять данные по истечении определенного периода времени? (Например, учетные записи клиентов должны быть удалены через три месяца или помечены как устаревшие и заархивированы во вторичной базе данных для будущего доступа). |
| Аутентификация | Требования безопасности для обеспечения того, чтобы пользователи были теми, за кого себя выдают. |
| Авторизация | Требования безопасности для обеспечения доступа пользователей только к определенным функциям в приложении (по сценарию использования, подсистеме, веб-странице, бизнес-правилам, уровню поля и т.д.). |
| Законность | В каких законодательных ограничениях работает система (защита данных, Sarbanes Oxley, GDPR и т.д.)? Какие права резервирования требуются компании? Любые правила, касающиеся способа создания или развертывания приложения? |
| Конфиденциальность | Возможность скрывать транзакции от внутренних сотрудников компании (зашифрованные транзакции, так что даже DBA и сетевые архитекторы не могут их увидеть). |
| Безопасность | Нужно ли шифровать данные в базе данных? Шифрование для сетевого взаимодействия между внутренними системами? Какой тип аутентификации необходим для удаленного доступа пользователей? |
| Поддерживаемость | Какой уровень технической поддержки необходим приложению? Какой уровень протоколирования и других средств необходим для отладки ошибок в системе? |
| Удобство использования/достижимость | Уровень подготовки, необходимый пользователям для достижения своих целей с помощью приложения/решения. К требованиям юзабилити нужно относиться так же серьезно, как и к любому другому архитектурному вопросу. |
Высокоуровневое представление системной архитектуры
Подробнее по теме предлагаем вам ознакомиться со следующими книгами:
Фундаментальный подход к программной архитектуре:
паттерны, свойства, проверенные методы
Марк Ричардс, Нил Форд
» Оглавление
» Отрывок
⠀
Современный подход к программной архитектуре: сложные компромиссы
Нил Форд, Марк Ричардс, Прамод Садаладж, Жамак Дехгани
» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — Заметки
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
P.S.
Также обращаем ваше внимание на то, что у нас на сайте проходит распродажа.
