Одной из целей SAD (документ по архитектуре программного обеспечения) является документирование важных архитектурных решений (тех, которые предполагают значительные затраты на изменение). Используемый стиль архитектуры является таким важным решением, поэтому его, вероятно, следует указать в SAD.
Но - это , действительно, стиль архитектуры такой важное решение? давайте предположим, что это не так. Разработчики, внедряющие систему, должны сами решить, какой стиль архитектуры использовать (если есть); для проекта со многими командами это может привести к использованию различных стилей для одной и той же категории требований. Поскольку разработчики (например, новые присоединяющиеся группы) могут не всегда знать обо всех контекстных ограничениях (в основном цель архитектора увидеть общую картину), они могут пропустить некоторые из них. В конце концов, конечный продукт может отлично работать для большинства ситуаций, но не для всех - например, он может быть недостаточно масштабируемым или не прост в обслуживании, и т. Д. c.
Но равен архитектурный стиль принцип ? Документ SAD может быть большим и охватывать множество различных ситуаций, поэтому не каждому будет просто осознать его в целом. С другой стороны, некоторые основные принципы c могут быть легко запоминаемы и соблюдаться. Разработчики лучше поняли бы намерения архитектора и чувствовали бы себя более комфортно, когда, например, дают оценки и рассуждают о том, чего ожидать в проекте. Имея дело с недостатками, типичными для архитектурного стиля, они ожидают, что будут использоваться известные общепринятые шаблоны и, вероятно, реализованы в качестве сквозных задач, повторно используемых компонентов. Таким образом, новые реализованные функции могут заканчиваться в существующем приложении (для архитектуры на основе монолитного c) или в другом (для архитектуры на основе микросервиса), даже если это может подразумевать такие сложности, как потеря транзакций ACID (но также такие преимущества, как увеличение масштабируемости). ). В конце концов, архитектор будет уверен, что команды, скорее всего, будут использовать аналогичный подход при работе с аналогичными требованиями.
Исходя из этого, я утверждаю, что стиль архитектуры ( microservice или другой ) всегда должен быть принцип, изложенный в САД.