Отказ от ответственности: я являюсь архитектором в гибкой среде , но, как Мольтке говорит: «Ни один план сражения не выдерживает контакт с врагом». Другими словами, практичность означает, что точная буква руководящих принципов не всегда может соблюдаться.
Большинство пунктов, поднятых выше, соблюдаются как можно лучше. Однако принципу 1 (команды, которые кодируют систему, разрабатывают систему) действительно трудно следовать, когда команда состоит из десятков (или сотен) разработчиков, разбросанных по разным континентам и часовым поясам . Это не имеет ничего общего с навыками или отношениями разработчиков, а скорее с их материально-технической проблемой, связанной с тем, чтобы собирать требования от клиентов и понимать существующие сложные системы.
Итак, как выполняется проектирование системы? Используете UML? Или документ, который определяет интерфейсы и основные блоки? Может быть, что-то еще?
Зачастую архитектор определяет основные компоненты, а затем определяет интерфейсы между ними (включая нефункциональные требования, такие как безопасность, скорость и надежность) и делегирует внутренний дизайн компонентов отдельным группам . Это хороший компромисс между тем, чтобы позволить командам разрабатывать свои собственные компоненты, не требуя, чтобы все знали все о системе.
Каждая организация имеет свой собственный набор стандартов для архитектурных проектов, и это иногда варьируется от проекта к проекту в рамках организации. Этот дизайн сделан до того, как команда начинает кодирование или как можно раньше и обычно содержит (и не полный список):
- Расширенные требования и определение области применения. К ним относятся сценарии использования или пользовательские истории, которые отражают бизнес-требования более высокого уровня. Мне лично нравится использовать RFC 2119 для нефункциональных требований. Дизайн основан и прослежен до них. Хотя это может не соответствовать общему определению дизайна, они часто так же важны.
- Обзор, состоящий из высокоуровневой схемы сети или компонентов и страницы текста. Это для очень широкой аудитории, от высшего руководства до разработчиков и QA. Это редко использует UML или определенные обозначения из-за широкой аудитории.
- Подробности для отдельных компонентов, часто с акцентом на интерфейсах или API между ними, как упомянуто выше. Интерфейсы могут быть указаны как сигнатуры методов на целевом языке с подробностями предусловия и постусловия. Компоненты могут иметь сетевые диаграммы, например, показывающие расположение виртуальных машин в облаке или центре обработки данных и их сетевые схемы. Реляционные базы данных обычно имеют диаграммы Entity-Relationship.
- Список архитектурных рисков и их снижение, если известно. Как и требования, они демонстрируют проектные решения и компромиссы.
Короче говоря, дизайн системы в гибком процессе точно такой же, как и в традиционном процессе с водопадом. Однако в гибких средах меньшая часть проекта выполняется заранее, а большая часть делегируется группам компонентов . Ключевым моментом является определение того, насколько глубоко идти на начальном этапе, какие решения откладывать и когда необходимо принимать решения. Решения, которые влияют на несколько групп разработчиков, должны приниматься раньше, особенно масштабируемость и безопасность. Такие решения, как добавление дополнительных языков к уже интернационализированному продукту, могут быть отложены до очень позднего срока.
После создания первоначального проекта архитектор работает с каждой из команд и просматривает их проекты. Если для единицы работы требуются дополнительные изменения в дизайне или дизайне (например, в спринте), архитектор стремится сделать его доступным к моменту начала этой единицы работы. Архитектор также несет ответственность за сообщение о любых изменениях затронутым командам или заинтересованным сторонам.