Comments 14
У Вас в Тексте Ошибка. Вместо " в чем состоит работа Архитектора?" Надо Писать "в чём состоит Работа Архитектора".
Так будет симметричнее.
Разделение на «реализацию» и «декларативность» является лишь частным случаем. В более общем случае можно языку реализации поставить в соответствие абстрактную алгебру (н-р алгебры Глушкова, хотя они слишком низкоуровневые). Каждый аспект архитектуры описывать в своей, удобной для этого алгебре (н-р в реляционной). В головах у людей, иногда в документах, есть намеки на гомоморфизмы алгебры реализации в алгебры архитектур. Совокупность этих гомоморфизмов отвечает на основные вопросы, как то — как устроена модель данных, апи, структура программы, распределение на модули и сервисы и т.п.
Такой образ мыслей позволяет не делить все на чёрное и белое, на реализацию и декларативную часть, а видеть иерархию моделей, в которой может быть сколько угодно уровней.
Гомомофизм (в общем виде) это отображение одной алгебры в другую с сохранением ее структуры. Например отображение четных целых чисел в 0 и нечетных в 1 кодирует их свойства. 0+0=0, четное + четное = четное; 0+1=1, четное + нечетное = нечётное. Таким образом гомоморфизм является механизмом абстракции, он убирает ненужные свойства и обставляет ту часть структуры, которая важна. Это и есть то, что мы хотим от архитектуры — посмотреть на систему игнорируя ненужные детали.
Другими словами вам нужны языки описания различных аспектов архитектуры и правила, по которым конструкции языка архитектуры отображаются в текст программы и связанные артефакты. Набор этих правил вместе с языками описания и будет является тем, что мы интуитивно называем «архитектура». Взгляд на эти языки и правила как на алгебры и гомоморфизмы позволяет держать иерархию языков/моделей в соотвествии друг другу.
Спасибо за развернутый комментарий и соображения. Кое в чем я хотел бы с вами
не то что поспорить, но по крайней мере уточнить.
1. Как мне кажется многие ваши соображения строятся на идеях Haskell, это просто наблюдение.
2. Про декларативность и алгебру — я использую термин декларативность для того
чтобы подчеркнуть отличие описания желаемого результата (декларативность) от
конкретного способа его достижения (имеративность). Ваши соображения про алгебру
имеют смысл, но алгебра сама по себе не дает свойства анализируемости. А в плане
описания архитектуры важно не только собственно само ее описание, но и возможность
представить это описание различными способами.
3. Про черное и белое — вы сами говорите «может быть сколько угодно уровней»,
и действительно, уровней абстракции может быть больше чем два. Но важно то что
эти уровни абстракции должны быть, и должно быть какие то компактное высокоуровневое
представление общей идеи которую можно рассматривать самостоятельно, не учитывая
все прочие более частные детали реализации. Иначе как во всем разобраться?
4. нужны языки описания различных аспектов архитектуры — не обязательно языки
в терминах языков программирования. и даже если язык есть — он сам по себе архитектурой
не является, но является средством ее выражения. Какие то архитектурные
свойства системы могут быть представлены просто в конфигурационных (yaml) файлах,
в аннотациях, в xml моделях или моделях описанных непосредственно на прикладном
языке программирования (но именно как декларация, т.е. модель).
Я понимаю общий смысл вашего комментария что в целом можно построить
единую формальную модель всего продукта в котором архитектура и реализация
будет органично (алгебры) стыковаться друг с другом с переходом от более высоких
уровней абстракции к, в конечном счете, к деталям реализации. Идеалистически
с вами можно было бы согласится.
не то что поспорить, но по крайней мере уточнить.
1. Как мне кажется многие ваши соображения строятся на идеях Haskell, это просто наблюдение.
2. Про декларативность и алгебру — я использую термин декларативность для того
чтобы подчеркнуть отличие описания желаемого результата (декларативность) от
конкретного способа его достижения (имеративность). Ваши соображения про алгебру
имеют смысл, но алгебра сама по себе не дает свойства анализируемости. А в плане
описания архитектуры важно не только собственно само ее описание, но и возможность
представить это описание различными способами.
3. Про черное и белое — вы сами говорите «может быть сколько угодно уровней»,
и действительно, уровней абстракции может быть больше чем два. Но важно то что
эти уровни абстракции должны быть, и должно быть какие то компактное высокоуровневое
представление общей идеи которую можно рассматривать самостоятельно, не учитывая
все прочие более частные детали реализации. Иначе как во всем разобраться?
4. нужны языки описания различных аспектов архитектуры — не обязательно языки
в терминах языков программирования. и даже если язык есть — он сам по себе архитектурой
не является, но является средством ее выражения. Какие то архитектурные
свойства системы могут быть представлены просто в конфигурационных (yaml) файлах,
в аннотациях, в xml моделях или моделях описанных непосредственно на прикладном
языке программирования (но именно как декларация, т.е. модель).
Я понимаю общий смысл вашего комментария что в целом можно построить
единую формальную модель всего продукта в котором архитектура и реализация
будет органично (алгебры) стыковаться друг с другом с переходом от более высоких
уровней абстракции к, в конечном счете, к деталям реализации. Идеалистически
с вами можно было бы согласится.
В качестве философских размышлений — статья вполне хороша. Но если бы Вы представили больше каких-то чисто практических советов, то было бы сильно лучше. Например утверждение о том, что на архитектуру можно писать тесты. Я бы посмотрел на ваши примеры и инструменты потверждающие это высказывание.
Спасибо за комментарий и за вопрос. Начну с того, почему ответить на ваш вопрос не
так просто, но один пример из практики привести попробую.
Некоторые примеры того что можно формально тестировать в контексте архитектуры
я приводил в самой статье, и тут я старался выбрать максимально простые и компактные примеры.
Но раз вы спрашиваете, этого вероятно недостаточно. А сложность специфического примера
в том что для его понимания нужно раскрыть много контекста, а это уже выходит
за рамки статьи, которая и без того получилась слишком длинной.
То что можно назвать из нашей практики. Например, мы умеем шифровать
пользовательские данные при сохранении их в базу данных, причем каждая
отдельная строка может шифроваться отдельный ключем. Более того, шифрованию
подлежат не все колонки, а только содержащие пользовательскую информацию.
Если в колонке хранится значение enum — его шифровать не нужно. У нас есть
расширенное определение домена хранения данных, в котором в частности
для каждого атрибута определяется — поделит ли он шифрованию или нет.
По этим meta-данным выполняется тест, который парсит код приложения и
выявляет места в которых поддержку шифрования добавить забыли.
Не знаю, насколько этот пример нагляден без подробного объяснения, но такой пример есть.
По правде, как это сейчас модно говорить, у нас самих есть большое количество
возможностей для улучшения, как вообще в плане определения архитектуры,
так и в аспектах ее тестирования. Но то что у нас что то получилось или не получилось,
не мешает вам попробовать сделать лучше. А идея, как мне кажется, достаточно простая.
так просто, но один пример из практики привести попробую.
Если в Архитектуру заложены определенные принципы, например, «клиентские приложения могут обращаться только к определенным типам микросервисов, но не ко всем», то при наличии модели коммуникации их можно проверять автоматически. Точно так же можно контролировать связи микросервисов и баз данных. Если есть определенные правила дизайна моделей данных, те же правила именования таблиц, то и их тоже можно проверять автоматически
Некоторые примеры того что можно формально тестировать в контексте архитектуры
я приводил в самой статье, и тут я старался выбрать максимально простые и компактные примеры.
Но раз вы спрашиваете, этого вероятно недостаточно. А сложность специфического примера
в том что для его понимания нужно раскрыть много контекста, а это уже выходит
за рамки статьи, которая и без того получилась слишком длинной.
То что можно назвать из нашей практики. Например, мы умеем шифровать
пользовательские данные при сохранении их в базу данных, причем каждая
отдельная строка может шифроваться отдельный ключем. Более того, шифрованию
подлежат не все колонки, а только содержащие пользовательскую информацию.
Если в колонке хранится значение enum — его шифровать не нужно. У нас есть
расширенное определение домена хранения данных, в котором в частности
для каждого атрибута определяется — поделит ли он шифрованию или нет.
По этим meta-данным выполняется тест, который парсит код приложения и
выявляет места в которых поддержку шифрования добавить забыли.
Не знаю, насколько этот пример нагляден без подробного объяснения, но такой пример есть.
По правде, как это сейчас модно говорить, у нас самих есть большое количество
возможностей для улучшения, как вообще в плане определения архитектуры,
так и в аспектах ее тестирования. Но то что у нас что то получилось или не получилось,
не мешает вам попробовать сделать лучше. А идея, как мне кажется, достаточно простая.
Шикарный текст. Единственная проблема — архитектура и реализация относительны.
Что именно является архитектурой и что именно является реализацией — зависит от точки зрения. Когда работаешь над одним отдельно взятым сервисом, оперируешь архитектурой №1. Когда работаешь над некоторой подсистемой включающей в себя сервис с архитектурой №1 и опирающиеся на него микросервисы с собственными архитектурами — оперируешь архитектурой №2. Когда поднимаешься до уровня системы состоящей из подсистем (одна из которых имеет архитектуру №2) — оперируешь архитектурой №3. С точки зрения архитектуры №3 — архитектура №1 это настолько мелкие детали реализации, что они не стоят упоминания. При этом сервис с архитектурой №1 может состоять из компонент с собственными архитектурами, а система с архитектурой №3 — может быть частью чего-то большего с собственной архитектурой.
Так что архитектура и реализация это условное деление. ИМХО архитектура это то, что позволяет «окинуть одним взглядом» или «запихнуть в голову за один присест» некоторый объем функционала. А реализация требует переключения контекста.
ЗЫ: бюрократия нужна как раз для возможности переключения контекста при работе с деталями реализации по частям.
Что именно является архитектурой и что именно является реализацией — зависит от точки зрения. Когда работаешь над одним отдельно взятым сервисом, оперируешь архитектурой №1. Когда работаешь над некоторой подсистемой включающей в себя сервис с архитектурой №1 и опирающиеся на него микросервисы с собственными архитектурами — оперируешь архитектурой №2. Когда поднимаешься до уровня системы состоящей из подсистем (одна из которых имеет архитектуру №2) — оперируешь архитектурой №3. С точки зрения архитектуры №3 — архитектура №1 это настолько мелкие детали реализации, что они не стоят упоминания. При этом сервис с архитектурой №1 может состоять из компонент с собственными архитектурами, а система с архитектурой №3 — может быть частью чего-то большего с собственной архитектурой.
Так что архитектура и реализация это условное деление. ИМХО архитектура это то, что позволяет «окинуть одним взглядом» или «запихнуть в голову за один присест» некоторый объем функционала. А реализация требует переключения контекста.
ЗЫ: бюрократия нужна как раз для возможности переключения контекста при работе с деталями реализации по частям.
Приятно слышать, большое спасибо.
Архитектура действительно иерархична — есть архитектура продукта, фичи, сервиса, модуля.
Что является архитектурой-архитектурой, а что реализацией — зависит от проекта.
Конечно, это зависит и от точки зрения, но я считаю важно формально определить
хотя бы какую то часть кода как архитектуру — иначе получается что есть только реализация и мнения. А с этим сложно работать.
Высокоуровневая архитектура, то что можно «окинуть одним взглядом», согласен с вами, это действительно важно. Должно быть хотя бы что то на этом уровне. Хотя бы понятные модели данных.
Архитектура действительно иерархична — есть архитектура продукта, фичи, сервиса, модуля.
Что является архитектурой-архитектурой, а что реализацией — зависит от проекта.
Конечно, это зависит и от точки зрения, но я считаю важно формально определить
хотя бы какую то часть кода как архитектуру — иначе получается что есть только реализация и мнения. А с этим сложно работать.
Высокоуровневая архитектура, то что можно «окинуть одним взглядом», согласен с вами, это действительно важно. Должно быть хотя бы что то на этом уровне. Хотя бы понятные модели данных.
Пожалуй, ни единого раза не сталкивался с тем, чтобы отсутствовала возможность перейти на уровень выше. Просто растет доля архитектуры бизнеса по отношению к архитектуре ПО. И вот чтобы четко выделить архитектуру-архитектуру ПО без бизнеса вообще — ни разу не встречалось. Проекты-то не в воздухе возникают.
Просто на глубоких уровнях влияние бизнеса выглядит как ключевые ограничения — типа система грузится с сетевого образа, файлы образа доступны только для чтения, локальный диск без рейда т.е. без гарантий и может отсутствовать вообще, все дисковые хранилища — маунты с нетаппов NFS или SAN/LUN если правильно помню. А на много уровней выше — HP дал выгодную цену на железо с технологией HP BladeSystem и запущен процесс оптимизации расходов. И где-то глубоко-глубоко в модуле управляющем временными файлами (вроде ж чисто разработка ПО) проявляется влияние бизнес процесса оптимизации расходов.
Из опыта:
При фрилансе на мелкого заказчика с запросом десктопного приложения — уровень перехода был в районе внешнего вида форм. А когда работал в крупном аутсорсере на большую международную компанию — примерный уровень перехода был выше диаграммы потоков данных. На уровне диаграммы потоков данных — веб-юай из пары апп хостов чисто для отказоустойчивости и минимального дб кластера и кластер из десятков апп хостов подпертый несколькими расширенными дб кластерами месящий террабайты данных в сутки изображались одинаковыми прямоугольниками, а стоили совершенно разные деньги. А прямоугольников на диаграмме десятки. Да и SLA из контрактов — это прохождение определенных данных по определенному пути — а на бабки в случае чего попадает бизнес. При этом в некоторых моментах бизнес-решения влияли на такие глубоко технические вещи, что сходу и не поверишь.
Для менеджера от бизнеса диаграмма потоков данных — паутина с квадратиками. Но если в квадратики к названиям продуктов добавить например ежемесячные расходы на содержание, а в уголке диаграммы — месячную прибыль от всей системы в целом, то пустота и растерянность в глазах менеджера сменяется осмысленным выражением. Или можно вписать не расходы на содержание, а стоимость внесения изменений. Или ожидаемые финансовые потери при сбое.
Что характерно, свеженанятый июнь будет смотреть на эту же диаграмму с точно такой же пустотой и растерянностью в глазах. Зато июнь оживет при виде UMLек с классами или схемами модели данных части одного из продуктов.
Попробую сформулировать еще раз. Есть реализация и ее представления на определенном уровне детализации. Представление может быть понятным или нет. Архитектура — это понятное слушателю/читателю/зрителю представление некоторого функционала который можно окинуть одним взглядом. Не обязательно это должны быть модели данных. Архитектурой для общения с человеком от бизнеса могут быть таблицы с колонками Дебет/Кредит/Баланс или Приход/Расход/Итого, для общения с человеком от UX — диаграмма переходов между экранами мобильного приложения и т.д.
Просто на глубоких уровнях влияние бизнеса выглядит как ключевые ограничения — типа система грузится с сетевого образа, файлы образа доступны только для чтения, локальный диск без рейда т.е. без гарантий и может отсутствовать вообще, все дисковые хранилища — маунты с нетаппов NFS или SAN/LUN если правильно помню. А на много уровней выше — HP дал выгодную цену на железо с технологией HP BladeSystem и запущен процесс оптимизации расходов. И где-то глубоко-глубоко в модуле управляющем временными файлами (вроде ж чисто разработка ПО) проявляется влияние бизнес процесса оптимизации расходов.
Из опыта:
При фрилансе на мелкого заказчика с запросом десктопного приложения — уровень перехода был в районе внешнего вида форм. А когда работал в крупном аутсорсере на большую международную компанию — примерный уровень перехода был выше диаграммы потоков данных. На уровне диаграммы потоков данных — веб-юай из пары апп хостов чисто для отказоустойчивости и минимального дб кластера и кластер из десятков апп хостов подпертый несколькими расширенными дб кластерами месящий террабайты данных в сутки изображались одинаковыми прямоугольниками, а стоили совершенно разные деньги. А прямоугольников на диаграмме десятки. Да и SLA из контрактов — это прохождение определенных данных по определенному пути — а на бабки в случае чего попадает бизнес. При этом в некоторых моментах бизнес-решения влияли на такие глубоко технические вещи, что сходу и не поверишь.
Для менеджера от бизнеса диаграмма потоков данных — паутина с квадратиками. Но если в квадратики к названиям продуктов добавить например ежемесячные расходы на содержание, а в уголке диаграммы — месячную прибыль от всей системы в целом, то пустота и растерянность в глазах менеджера сменяется осмысленным выражением. Или можно вписать не расходы на содержание, а стоимость внесения изменений. Или ожидаемые финансовые потери при сбое.
Что характерно, свеженанятый июнь будет смотреть на эту же диаграмму с точно такой же пустотой и растерянностью в глазах. Зато июнь оживет при виде UMLек с классами или схемами модели данных части одного из продуктов.
Попробую сформулировать еще раз. Есть реализация и ее представления на определенном уровне детализации. Представление может быть понятным или нет. Архитектура — это понятное слушателю/читателю/зрителю представление некоторого функционала который можно окинуть одним взглядом. Не обязательно это должны быть модели данных. Архитектурой для общения с человеком от бизнеса могут быть таблицы с колонками Дебет/Кредит/Баланс или Приход/Расход/Итого, для общения с человеком от UX — диаграмма переходов между экранами мобильного приложения и т.д.
Пожалуй, ни единого раза не сталкивался с тем, чтобы отсутствовала возможность перейти на уровень выше.
Интуитивно, чисто теоретически, думаю можно написать такой код который нельзя будет абстрагировать. Существует же Теорема Гёделя о неполноте. Но на практике я с вами полностью согласен.
И вот чтобы четко выделить архитектуру-архитектуру ПО без бизнеса вообще — ни разу не встречалось. Проекты-то не в воздухе возникают.
Из ваших слов мне кажется что у вас сложилось впечатление будто бы я позиционирую
архитектуру отдельно от продукта. Это совершенно не так. Смотрите:
А еще Архитектура — это то, каким образом приложение выполняет свое предназначение.
Конечно, архитектура должна в первую очередь выражать смысл продукта и его прикладную область, а технологии и сложности реализации тут вторичны (хотя их и приходится учитывать в архитектуре).
—
уровень перехода [к архитектуре] был в районе внешнего вида форм
Вы подняли интересную тему, которую мне не удалось вместить в объем статьи.
Еще Ф.Брукс младший писал (цитата не точная) что Архитектура это в первую
очередь интерфейс продукта и пользователя. В 1960-х это были инструкции
к программному обеспечению и параметры консольных команд. Тогда это были
чисто технические вещи. Суть я считаю не поменялась, но измелились технологии.
Сейчас интерфейс с пользователем почти всегда графический, и его проектирование
занимаются UX-дизайнеры. Тут получается любопытный парадокс. С одной стороны
часто кроме макетов интерфейса ничего нет. При, по факту, такие макеты и являются
единственным определением архитектуры. Те есть получается что работу архитектора
делает UX-дизайнер. Лично мне достаточно часто приходится сталкиваться с тудностями
такого подхода, когда архитектура вроде бы уже определена макетыми, эти макеты
уже со всеми согласованы, может быть даже разработка начата, но по факту макеты
поверхностные. Каждый из них в отдельности красивы, но консистентной внутренней
логики за ними не получается. Мне кажется что перекос архитектуры в сторону UX
сейчас слишком велик, и причина в том что макеты дизайнера гораздо нагляднее
того что может предложить архитектор. А люди, особенно менеджеры, склонны соглашаться
с тем что _выглядит_ проще, даже если на самом деле это не так.
При этом в некоторых моментах бизнес-решения влияли на такие глубоко технические вещи, что сходу и не поверишь.
Поделитесь если не секрет, очень любопытно.
Для менеджера от бизнеса диаграмма потоков данных — паутина с квадратиками. Но если в квадратики к названиям продуктов добавить например ежемесячные расходы на содержание, а в уголке диаграммы — месячную прибыль от всей системы в целом, то пустота и растерянность в глазах менеджера сменяется осмысленным выражением.
Согласен с вами, это очень разумный подход.
Зато июнь оживет при виде UMLек с классами или схемами модели данных части одного из продуктов.
Про модели данных также с вами согласен. Но UML диаграммы классов? Мне кажется
эта концепция устарела. Современные среды разработки дают шикарные возможности
по работе с кодом и навигации по нему, зачем нужны диаграммы классов я искренне не
понимаю. На мой вкус это уже аспект реализации и притом некий атавизм в виде блок схем которые рисовали на алгоритмы в третьей четверти прошлого века.
Как-то UML совсем забыли даже упомянуть.
Прошу прощения что затянул с ответом, не хотелось отвечать на вопрос впопыхах.
Изначально я планировать в статье раздел про UML, потом отказался от этой идеи
поскольку объем статьи и без того получился изрядный, а прям пользы от темы UML мало.
Мое отношение к UML следующее: UML это неудачная попытка микроменеджить реализацию.
Утверждение достаточно острое, постараюсь пояснить его на примере и в исторической перспективе.
Пример. Один мой однокурсник как то поделился жизненным опытом. Он работал
в outsource компании, и его подключили к реализации очередного проекта.
Проект как раз был «спроектирован» в UML «настоящими архитекторами». То есть в
разработку передали автоматически сгенерированный код проекта, со всеми классами,
интерфейсами и рыбами методов. Собственно разработчиком нужно было «всего лишь»
написать реализацию каждого метода. Дословно передать что мой товарищ сказал о
такой «архитектуре» я не могу, в печати такие термины использовать не принято.
Суть его соображений сводилась к тому что это был очень плохой подход.
Глубокого исторического исследования именно UML я не проводил, но у меня
есть некоторые соображения на эту тему на основе книги Ф.Брукса «Мифический Человеко-месяц»
На заре программирования (в 40-х), когда программы писались непосредственно в машинных
кодах, имел смысл планировать алгоритмы в виде блок-схем (в университетах возможно
и по сей день этому учат). Тогда в этом был смысл, поскольку программы были очень маленькие, а выразительные средства программиста (машшинный код) очень бедные.
Но уже с появлением assembler необходимость в блок схемах отпала. Тем не менее,
разработчиков еще несколько десятилетий заставляли рисовать блок-схемы их алгоритмов,
в автоматизации чего разработчики крайне преуспели. Тогда было модно хвастаться
своими разработками по автоматической генерации блок-схем из кода (о чем пишет Брукс).
Меньше в 80-х, и в пике в 90-х, в программировании доминировала концепция ООП.
Тогда казалось что вот он «святой грааль» программирования, у нас теперь есть объекты,
и в их терминах наконец то можно будет описывать высокоуровневое представление системы.
(Такие мысли выражает Брукс в дополнении ко второму изданию книги, от 95 года).
Я так понимаю что UML как раз и был той попыткой сделать язык описания архитектуры
в терминах ООП. Попыткой провальной. Если бы UML имел успех — мы бы им пользовались постоянно. В вопросе дизайна кода победили современны среды разработки,
предоставляющие обширный инструментарий рефакторинга кода (IntelliJ IDEA вышла в 2001).
Идеи заложенные в UML ведут к слишком детальному описанию, которое практически
идентично реализации, но ей не являются. А для разработки реализации не нужны
схемы и диаграммы, для реализации логики нужны полноценные инструменты рефакторинга.
Изначально я планировать в статье раздел про UML, потом отказался от этой идеи
поскольку объем статьи и без того получился изрядный, а прям пользы от темы UML мало.
Мое отношение к UML следующее: UML это неудачная попытка микроменеджить реализацию.
Утверждение достаточно острое, постараюсь пояснить его на примере и в исторической перспективе.
Пример. Один мой однокурсник как то поделился жизненным опытом. Он работал
в outsource компании, и его подключили к реализации очередного проекта.
Проект как раз был «спроектирован» в UML «настоящими архитекторами». То есть в
разработку передали автоматически сгенерированный код проекта, со всеми классами,
интерфейсами и рыбами методов. Собственно разработчиком нужно было «всего лишь»
написать реализацию каждого метода. Дословно передать что мой товарищ сказал о
такой «архитектуре» я не могу, в печати такие термины использовать не принято.
Суть его соображений сводилась к тому что это был очень плохой подход.
Глубокого исторического исследования именно UML я не проводил, но у меня
есть некоторые соображения на эту тему на основе книги Ф.Брукса «Мифический Человеко-месяц»
На заре программирования (в 40-х), когда программы писались непосредственно в машинных
кодах, имел смысл планировать алгоритмы в виде блок-схем (в университетах возможно
и по сей день этому учат). Тогда в этом был смысл, поскольку программы были очень маленькие, а выразительные средства программиста (машшинный код) очень бедные.
Но уже с появлением assembler необходимость в блок схемах отпала. Тем не менее,
разработчиков еще несколько десятилетий заставляли рисовать блок-схемы их алгоритмов,
в автоматизации чего разработчики крайне преуспели. Тогда было модно хвастаться
своими разработками по автоматической генерации блок-схем из кода (о чем пишет Брукс).
Меньше в 80-х, и в пике в 90-х, в программировании доминировала концепция ООП.
Тогда казалось что вот он «святой грааль» программирования, у нас теперь есть объекты,
и в их терминах наконец то можно будет описывать высокоуровневое представление системы.
(Такие мысли выражает Брукс в дополнении ко второму изданию книги, от 95 года).
Я так понимаю что UML как раз и был той попыткой сделать язык описания архитектуры
в терминах ООП. Попыткой провальной. Если бы UML имел успех — мы бы им пользовались постоянно. В вопросе дизайна кода победили современны среды разработки,
предоставляющие обширный инструментарий рефакторинга кода (IntelliJ IDEA вышла в 2001).
Идеи заложенные в UML ведут к слишком детальному описанию, которое практически
идентично реализации, но ей не являются. А для разработки реализации не нужны
схемы и диаграммы, для реализации логики нужны полноценные инструменты рефакторинга.
Прекрасная статья. Но есть много но. Выбор языка программирования, СУБД, брокера сообщений, необходимого железа, протокола — это императивные решения. Но они тоже, как правило, относятся к ведению архитектора и в подавляющем большинстве случаев являются частью архитектуры. Так же частью архитектуры являются решения по способу реализации наиболее критичных частей системы.
При этом декларативные SQL-запросы почти никогда не относятся к архитектуре (структура запросов, например, избежание JOIN-ов ради данных в кеше — может относиться). Схема БД иногда относится к архитектуре, а иногда нет. Например, если система разбита на мелкие микросервисы с собственными БД, то схемы этих БД зачастую не относятся к архитектуре — их можно в любой момент переписать и поэтому их структура не важное решение и точно не важнейшее.
В это прекрасной статье автор сделал классическую ошибку — вместо архитектуры (Architecture) он описал дизайн (Design) системы. Да, сейчас в индустрии разработки ПО редко отделяют дизайн (форму системы) от архитектуры (содержания системы), но высококлассный архитектор должен удерживать это различие в уме.
При этом декларативные SQL-запросы почти никогда не относятся к архитектуре (структура запросов, например, избежание JOIN-ов ради данных в кеше — может относиться). Схема БД иногда относится к архитектуре, а иногда нет. Например, если система разбита на мелкие микросервисы с собственными БД, то схемы этих БД зачастую не относятся к архитектуре — их можно в любой момент переписать и поэтому их структура не важное решение и точно не важнейшее.
В это прекрасной статье автор сделал классическую ошибку — вместо архитектуры (Architecture) он описал дизайн (Design) системы. Да, сейчас в индустрии разработки ПО редко отделяют дизайн (форму системы) от архитектуры (содержания системы), но высококлассный архитектор должен удерживать это различие в уме.
Большое спасибо за комментарий, простите что отвечаю с большой задержкой, был в отпуске.
Не знаю насколько мне удалось это донести в статье, но я имел в виду что в различных проектах под Архитектурой могут пониматься совершенно разные вещи (и это нормально). Важно четко понимать, что в вашем проекте Архитектура, а что Реализация.
Примеры которые вы приводите можно отнести в категорию «фундаментальные решения» или «то что дорого изменить», и они вполне могут быть отнесены к Архитектуре. Но не обязательно.
Например, подбор конкретного железа это скорее вопрос обслуживания Production, чем Архитектурный. Повторюсь: если для конкретного проекта правильный выбор железа критически важен (и его следует делать с пониманием внутреннего устройства системы), — этот вопрос может быть и Архитектурным.
Сам по себе полный перечень SQL запросов к Архитектуре (скорее всего) не относится.
Но возможность использовать в реализации SQL запросы «защищает» Архитектуру
от необходимости описания всех возможных (используемых) способов получения данных.
При этом запрет на JOIN, это определенно Архитектурное решение. И на это решение
можно вполне написать тест, который будет проверять реализацию (сам код) на соответствие этому принципу.
Хороший пример. Конечно, схема БД это не всегда Архитектура. В вашем примере схему
хранения данных вполне можно считать деталью реализации (при условии что сервисы
действительно не имеют доступа к базам друг друга). Но что в этом случае Архитектура?
Вероятно API.
Дизайн, визуальное представление (форма системы), это важная часть Архитектуры.
Понять устройство системы не имея никакого ее графического выражения представляется крайне затруднительным. Но вы правы, Архитектура это не только дизайн. Например,
принципы организации микросервисов это тоже Архитектура.
Не знаю насколько мне удалось это донести в статье, но я имел в виду что в различных проектах под Архитектурой могут пониматься совершенно разные вещи (и это нормально). Важно четко понимать, что в вашем проекте Архитектура, а что Реализация.
Выбор языка программирования, СУБД, брокера сообщений, необходимого железа, протокола [...] относятся к ведению архитектора и в подавляющем большинстве случаев являются частью архитектуры. Так же частью архитектуры являются решения по способу реализации наиболее критичных частей системы.
Примеры которые вы приводите можно отнести в категорию «фундаментальные решения» или «то что дорого изменить», и они вполне могут быть отнесены к Архитектуре. Но не обязательно.
Например, подбор конкретного железа это скорее вопрос обслуживания Production, чем Архитектурный. Повторюсь: если для конкретного проекта правильный выбор железа критически важен (и его следует делать с пониманием внутреннего устройства системы), — этот вопрос может быть и Архитектурным.
При этом декларативные SQL-запросы почти никогда не относятся к архитектуре (структура запросов, например, избежание JOIN-ов ради данных в кеше — может относиться).
Сам по себе полный перечень SQL запросов к Архитектуре (скорее всего) не относится.
Но возможность использовать в реализации SQL запросы «защищает» Архитектуру
от необходимости описания всех возможных (используемых) способов получения данных.
При этом запрет на JOIN, это определенно Архитектурное решение. И на это решение
можно вполне написать тест, который будет проверять реализацию (сам код) на соответствие этому принципу.
Схема БД иногда относится к архитектуре, а иногда нет. Например, если система разбита на мелкие микросервисы с собственными БД, то схемы этих БД зачастую не относятся к архитектуре — их можно в любой момент переписать и поэтому их структура не важное решение и точно не важнейшее.
Хороший пример. Конечно, схема БД это не всегда Архитектура. В вашем примере схему
хранения данных вполне можно считать деталью реализации (при условии что сервисы
действительно не имеют доступа к базам друг друга). Но что в этом случае Архитектура?
Вероятно API.
Дизайн, визуальное представление (форма системы), это важная часть Архитектуры.
Понять устройство системы не имея никакого ее графического выражения представляется крайне затруднительным. Но вы правы, Архитектура это не только дизайн. Например,
принципы организации микросервисов это тоже Архитектура.
Sign up to leave a comment.
Архитектура — Декларативна. Реализация — Императивна. Все остальное — Бюрократия