Gaperton on Software Architecture
Что такое архитектура ПО, чем она отличается от "дизайна", и что же все-таки является входными данными для разработки архитектуры. Дискуссия на РСДН по данному вопросу была изумительна.
Оказывается, распространено мнение, что мол принципиальных отличий между "архитектурой" и "дизайном" нет. Некоторые идут дальше, и заявляют, что "архитектура" ( Read more... )
Конечно.
"Еще ни строчки вообще ни какого кода не написано, еще ни какой декомпозиции не провели, но выбрали тот же MySQL только потому, что знаем его лучше. Разве не получается, что сначала было принято архитектурное решение и лишь потом мы беремся за дизайн?"
Получается.
"И если в будующем общие требования к производительности повысятся, а дизайн был спроектированн верно, то переход на другую СУБД будет выполнен малой кровью и потребуется переписать только часть кода который относится к работе с MySQL вместе переписывания системы в целом."
Думаю, если вы заранее закладываетесь на возможную замену СУБД - это тоже определенное архитектурное решение. Выливающееся, скажем, в отказе от использования Transact-SQL (если у вас не MySQL а MS SQL в начале), или в выделении и минимизации слоя, зависимого от СУБД в явном виде.
Короче, структура "слоев", из которых состоит приложение (layered architecture) - тоже относится к архитектуре. Вот, например, способ подразбиения стека протоколов TCP/IP на отдельные протоколы - это ни что иное как выделение слоев, дающих определенные группы сервисов, и это архитектурное решение.
Reply
А вообще существует ли какой определенный набор признаков по которым я, рассматривая какую либо систему (которую не я писал), могу скачать, что вот это архитектурное решение, а вот тут дизайн? Потому что на примере стека я бы скорее подумал, что это дизайн. Разве мысль разделить системы на ряд слоев и создание OSI сетевой модели это не дизайнеркое решение? Ведь разработчики могли все запихать и в один протокол, вот DoD ограничился только 4-мя уровнями.
Reply
Все станет гораздо проще и понятнее, если Вы откажетесь от употребления слова "архитектура", заменив его достаточно устойчивым, но более конкретным термином Common Design Principles. Понятия не имею, как это хорошо перевести на русский - как Вам нравится. (А термин "архитектор" - на не несущий лишнего смысла термин "technical lead")
Короче, разница между design principle и design уже более проста, и интуитивно понятна. Описание принципа подразбиения на уровни в TCP/IP - это одно. Описание стека протоколов, реализующего этот принцип - это уже другое. Понимание _принципов устройства_ системы позволяет Вам легко ориентироваться в самом _устройстве_.
Понимание "архитектуры", как его передаю я - это и есть "принципы" устройства. Принцип подразбиения системы на сервисы и на слои (не интерфейсы между ними (дизайн) и не протоколы взаимодействия (детальный дизайн, ибо в протоколе есть время)), - это "архитектура". Каким образом вы увязываете сервисы для решения Ваших задач - это уже "дизайн". Как сервисы и слои устроены - это также дизайн.
Вообще, TCP/IP достаточно запутанный пример. Потому, что даже детальное описание этого стека протоколов как единое целое, со всеми деталями, гхм, само является "архитектурным ограничением" для реализации данного стека. То есть, налицо некоторая "рекурсивность", когда то, что "архитектура", а что - нет - зависит от точки зрения.
Разработчики микропроцессоров имеют дело с той же проблемой, и поэтому выделяют терминологически "архитектуру системы команд" (instruction set architecture), и "микроархитектуру" (устройство проца, реализующего систему команд). Как пример - ISA SPARCv8 допускает самые разные "микроархитектуры" - начиная от простого процессора для встраиваемых приложений Leon3, и заканчивая зверской Сановской Ниагарой, не имеющего с Leon3 вообще ничего общего. Кроме системы команд. Правда, у ниагары SPARCv9.
Короче, не надо пользоваться термином "архитетура" лучше :). Во избежание.
Reply
- или вообще требованием. Тут, опять же, все зависит от точки зрения. "Архитектура" и "дизайн" - не существуют сами по себе. "Архитектура" и "дизайн" - это _свойства_ конкретных вещей, в определенном контексте, а не отдельно существующие вещи или артефакты.
Непонимание этого - также причина путаницы. Вот рядом меня спрашивает Локотков - есть ли архитектура у приложения, у которого пропали исходники? Занятный вопрос, не так ли? А вот я задам встречный вопрос - мы приложение еще не написали, но продумали - у него кода нет, а архитектура - есть или нет?
При понимании того, что "архитектура" на самом деле не "существительное", а "прилагательное" ;) такие вопросы не встают :).
Reply
Лично мне кажется, что там все есть. Пришел, к примеру, на завод новый станок. Как в нем и что, даже как с ним нужно работать еще не понятно (бывают и клинические случаи, когда к механизму ни чего вообще нет, абсолютно черный ящик), но в нем есть все, и архитектура, и дизайн и много чего еще. Поэтому по мне любая работающая сущность (программа ли, механизм ли) в себе уже все содержит. Когда мы понимает внутренюю логику работы этого механизма, то даже без схемы может его починить. Наверное о сабже проще буд
ет думать в критериях механизмов.
"А вот я задам встречный вопрос - мы приложение еще не написали, но продумали - у него кода нет, а архитектура - есть или нет?"
Как я понимаю, если мы не задались конкретными реализациями, то еще нет. Т.е. пока имеем абстрактную модель архитектуры нет. Как только мы решаем, что вот эта часть системы у нас будет реализованна на готовом решинии ХХ (данные храним в РСУБД MS SQL, к примеру), то архитектура появляется. По крайне мере я это понял так.
"При понимании того, что "архитектура" на самом деле не "существительное", а "прилагательное" ;) такие вопросы не встают :)."
Ну вот именно так об этом думать достаточно трудно...
Reply
С другой стороны, выделение этих принципов в явном виде, размышление над ними, и следование им при дизайне - позволяет Вам сделать устройство системы более простым, логичным, понятным, и не запутаться при этом.
Reply
Leave a comment