Архитектура дизайн это что
Что такое архитектура и дизайн
Архитектура и дизайн интерьеров неизменно сопровождают человека всю жизнь. Начиная с древних времен, когда люди строили простейшие сооружения для жизни и заканчивая высокотехнологическими современными зданиями архитектура и дизайн тесно связалась с нашей жизнью, работой, отдыхом и передвижением. Архитектура связывает между собой все аспекты нашего повседневного быта, начиная от дома и улицы, заканчивая бизнес центром, театром или стадионом.
Строительство и технический прогресс
Дизайн зданий варьируется в зависимости от страны, города и года создания, воплощая идеи архитектора и отображая определенные тенденции в архитектуре. Изучая здания из различных эпох, можно отследить изменения в дизайне, появление новых форм архитектуры (амфитеатры, стадионы и т.д.), а также определенный технический прогресс.
С развитием технологий, в строительстве начали использовать как натуральные материалы (дерево, камень, стекло), так и качественные износостойкие материалы, полученные искусственным путем. Прогресс также повлиял на внешний вид зданий – этажей становится все больше, а дизайн становится все изощреннее. Казалось бы, что уже все давно придумали, но современные архитекторы регулярно удивляют нас новыми и оригинальными проектами, украшая мир и привнося в него новые предметы искусства.
Изучение архитектуры
Архитектура и дизайн включают в себя довольно обширный спектр знаний, поэтому обучение этому искусству занимает много времени и сил. Благодаря различным онлайн порталам, как, например, The Architect, можно разбавить сухие лекции в университете интересной и живой информацией с наглядным примером современных зданий и проектов. Такие онлайн ресурсы также помогут найти друзей по интересам, с которыми можно бесконечно обсуждать архитектурные стили и последние строительные технологии.
Говоря об архитектуре, мы часто упоминаем именно здания и строительство. Однако, ландшафтный дизайн занимает довольно большую нишу в этой сфере и неразрывно связан с архитектурой домов и городов. Различные парки отдыха, сады и частные дворики дополняют дома и оживляют общий вид улицы или города. Невозможно представить Нью-Йорк без его Центрального парка, расположившегося посреди бетонных джунглей, а Париж без роскошного Сада Тюильри, созданного еще в 16-м веке.
Как видите, архитектура и дизайн понятия довольно обширные и многогранные. Изучая архитектуру, мы погружаемся в мир искусства и технологий, где творчество и креатив неразрывно связаны с точностью и скрупулезностью. Но несмотря на столь непростую науку, мир архитектуры не может не привлекать к себе внимание. Ведь созерцание прекрасного обогащает наш внутренний мир и делает нас немного лучше.
Добавлено: 28.02.2017 15:07:39
Еще статьи в рубрике Интерьерные решения от дизайнеров интерьера и производителей:
Архитектура & Дизайн – Дизайн & Архитектура
Жизнь не стоит на месте. Меняется человек, развивается общество, выдвигаются все новые и новые требования к среде обитания. Архитектура всегда отражала в своих произведениях как в зеркале периоды человеческого бытия, их тенденцию, моду, социально-экономический уклад, эстетические взгляды. И мы можем видеть, как на этом пути постоянно менялись цели, которые ставили себе зодчие, менялись средства для их достижения, но всегда присутствовало стремление к совершенству и совершенствованию.
Нельзя не заметить, что нынешний этап развития человеческой цивилизации добавил к традиционным средствам архитектурного творчества новую форму искусства – дизайн. В современном мире архитектура и дизайн стали неотъемлемыми составляющими жизнедеятельности человека. Дизайн – явление XX в. – активно развивался в течение всего столетия. Архитектура к началу ХХI в., хотя и с очень большим сопротивлением, позволила ему войти в свои владения, начиная проектировать не отдельные детали и фрагменты нашего окружения (дома, дороги, благоустройство), а все обстоятельства и формы существования вместе как целое – т.е. среду. И мировая архитектурная практика показывает, что там, где есть творческое содружество архитектуры и дизайна, есть произведение искусства.
Мы живем в материальном окружении, где активной трансформации подвержены многие аспекты человеческой жизни, тенденции развития сознания, нравов, технических и научных достижений, а во главе данных изменений становятся технология и коммуникация. Город находится на сложном и противоречивом этапе своей эволюции. “Современный город – это своеобразное отражение информационного общества, его кризисов, тупиков и его возрождений”. Городская среда стала более многоликой, сложной по своей структуре, связям, возникающим между элементами систем. Перед современным архитектором возникает такое многообразие задач, которое порой выходит за рамки традиционных для архитектурной школы объектов изучения и проектирования. И начинаешь понимать, что для их решения уже не хватает ни практических (традиционных технологий проектирования), ни теоретических знаний.
Необходим другой, новый мировоззренческий взгляд на средовое творчество. В этом плане будущее видится за содружеством архитектуры и дизайна, имеющих больше схожести, чем различий. Самостоятельной задачей средового проектирования стало сегодня формирование не столько окружения некоего процесса или события, сколько самого этого события. Именно так “оформляются” праздничные мероприятия. Тот же принцип – проектирование сначала процесса, “сценария”, а уже затем сопровождающих его обстоятельств – действует при организации световых “шоу” в среде исторических городов, при строительстве развлекательных парковых комплексов, крупных мемориальных ансамблей. Особую сферу архитектурно-дизайнерских поисков образуют мобильные средовые объекты. В проектировании, базирующемся на принципах средового подхода, изменяется отношение к объектам дизайна и архитектуры. Так, “их создание уже не является конечным результатом проектирования… они рассматриваются не как самоценные формы, а как средства, обеспечивающие оптимальные условия жизнедеятельности”. Развитие новых технологий трансформируют многочисленные процессы метаболизма города, добавляя к урбанистической структуре дополнительный пласт – информационный. Меняется и роль дизайна в формировании городской среды. Она смещается от преобразования материального наполнения и формирования ее стилистической окраски к осмыслению ее цифрового аспекта, выявлению коммуникационного потенциала и приведению к согласию с современной моделью мира, где доминирующей материей оказывается информация.
Необходимо осмысление этих сложных, неоднозначных процессов, происходящих в среде обитания человека. Это непростая задача. И решать ее надо, используя все возможные средства, потому что среда обитания человека должна быть средой для Человека. Полная переоценка целей и возможностей архитектурного искусства наблюдается и в сегодняшней мировой практике. Жан Нувель, может, и несколько радикально, заявил нечто для “нормальных” архитекторов немыслимое: “будущее архитектуры – неархитектурно”. Разъяснив свой тезис не менее загадочно: “архитектура не является… предметом необоримых законов… она движется поверх рамок, определяемых временем, и приспосабливает его законы к новому развитию. Сущность архитектуры – нарушать собственные пределы”.
Архитектурный дизайн видится следующим шагом в развитии архитектуры как искусства. Современная городская среда предоставляет комплекс условий для творческой деятельности, формирующей новые направления в науке, искусстве, культуре и т.д. Архитектурный дизайн как раз и является тем новым в искусстве, которое позволяет использовать не только традиционные средства архитектуры и дизайна, но и задействовать современные, такие как интерактивная архитектура, интерактивный дизайн, причем в комплексе решая функциональные и эстетические задачи.
С помощью средств архитектурного дизайна возможно полностью изменить восприятие среды; изменить сценарии, по которым живут городские пространства; при реконструкции превратить рядовой городской интерьер в средовой ансамбль.
Архитектурный дизайн – относительно молодая сфера проектной деятельности, отсюда некоторая фрагментарность рекомендательных указаний и правил по нему. Еще предстоит выработать общие подходы и условия применения стандартов и правил, используемых в проектных решениях компонентов среды. Так как это направление довольно новое для республики, сейчас можно говорить лишь об участии профессионалов в отдельных направлениях архитектурного дизайна: Е. Агранович-Пономарева, А. Боярина, П. Войницкий, Л. Еременко, Н. Клинова, А. Литвинова, А. Локотко, О. Минаков, А. Мыцких, А. Новиков, Д. Сидельников, В. Сокол, О. Телепнева, А. Трусов, В. Ционская, В. Щедрин и др.
Идет теоретическое осмысление архитектурного дизайна, методологическое обоснование. На это направлена тематика кандидатских и магистерских исследований, проводимых в рамках научных исследований кафедры “Дизайн архитектурной среды”. Новое направление развивается. В нем уже работают выпускники архитектурного факультета по специализации “Урбодизайн”. В 2011 г. состоится первый выпуск архитекторов-дизайнеров. Вот за ними – будущее.
Архитектор-дизайнер – это не дань моде. Это нормальная реакция на возникающие задачи в профессиональной деятельности, которая отвечает государственной стратегии развития архитектуры и строительства, связанной с качественным улучшением существующей предметно-пространственной среды дома, села, города, пространства страны. Исходным и важнейшим моментом концепции архитектурно-дизайнерского образования является представление об архитектурном дизайне как о новом виде пластического искусства, основанном на традициях архитектуры с использованием возможностей современного дизайна эстетически обогатить архитектурную среду и экологически оптимизировать урбанизированные пространства. Данная концепция базируется на развитии традиций белорусской архитектурной школы – это теория комплексного художественно-композиционного и научно-технического образования на общей широкой гуманитарной основе. Стержнем профессиональной подготовки архитекторов-дизайнеров является постоянная учебная проектная работа в рамках дисциплины “Архитектурно-дизайнерское проектирование”, изучение которой начинается с 1-го семестра 1-го курса и заканчивается выполнением дипломного проекта или дипломного проекта с развитой научно-исследовательской частью.
Динамично модифицирующиеся виды и формы традиционной организации предметно-пространственных комплексов, меняющиеся жизненные реалии требуют появления, а стало быть, прогнозирования и проектирования новых средовых объектов и систем. Одни появляются в ходе проведенных “поисковых” конкурсов среди студентов архитектурно-дизайнерских специальностей, цель которых – выявить нестандартные, даже фантастические варианты развития нынешних ситуаций. Другие темы возникают из требований реальности. Некоторые становятся результатом дипломной или магистерской работы студентов, чьи проекты уже достаточно масштабны, чтобы быть учебной работой, но еще не скованы грузом норм и правил, выработанных практикой вчерашнего дня.
Возникают работы по комплексной организации облика среды в масштабе большого градостроительного образования, это архитектурно-дизайнерское проектирование в классе крупных средовых систем. Здесь необычность двойная – впервые облик городской среды рассматривается как интегральное воздействие на зрителя всех ее слагаемых, в том числе мероприятий по временному оформлению городских пространств, но результатом проектирования является не единичная форма городского интерьера – площадь или улица, а совокупность городских пространств, подчиненных общей архитектурно-дизайнерской идее создания определенного образа. Такой в реальном проектировании стала научно-проектная разработка “Архитектурно-дизайнерская концепция пешеходного пространства в районе улиц Суворова и Ленина в г. Витебске” (рук. А.А. Литвинова, исполнители: С.Я. Слаук, И.В. Порубова, Е.Г. Козакова, М.Ю. Борисова, Н.В. Лукина, Е.А. Терентьев), в учебном проектировании – дипломный проект “Интегральные варианты композиционных структур в дизайне архитектурной среды (на примере Логойска)”, выполненный студентом А.А. Локотко под руководством А.А. Литвиновой (диплом 1-й степени Республиканского смотра-конкурса лучших дипломных проектов в Минске, 2007).
Для создания оптимального диалога между человеком и урбанистической средой XXI в. современная проектная практика вырабатывает единую методологическую базу, стратегию и логику организации города, опираясь на возможности реализации цифровых интерактивных систем. Работой в этом направлении стала магистерская диссертация А.В. Новикова (рук. А.А. Литвинова) “Современные принципы восприятия и формирования интерактивной среды в городском интерьере”, в которой рассмотрены особенности интерактивности в архитектуре, предложен алгоритм формирования интерактивной среды города, опирающийся на средства интерактивных дизайна и искусства.
Особую форму поискового средового проектирования составляет чисто художественный, эстетический эксперимент. Он зачастую связан с проверкой, освоением какого-нибудь содержательного начала в проектировании: новое понимание пространственных ощущений, использование новых средств создания декоративного эффекта, неожиданное сочетание материалов, непривычная работа традиционной формы и т.д., но результатом всегда является художественное открытие: непривычное эмоциональное состояние, новая выразительность старых слагаемых, свежая визуальная идея. Иначе говоря – новый способ организации и восприятии среды. Такой поисковой работой стал дипломный проект “Архитектурный дизайн в диалоге “Человек – Urban space” дипломника Е.Г. Козакова, руководитель А.А. Литвинова (диплом 1-й степени Республиканского смотра-конкурса лучших дипломных проектов высших архитектурных школ РБ в Минске, диплом 2-й степени Международного смотра-конкурса лучших дипломных проектов архитектурных школ, Самара, Россия, 2008).
Совместное рассмотрение многообразия форм и видов средовых систем, которые составляют предмет профессиональной деятельности архитектора-дизайнера, позволяет сделать вывод о принципиальных тенденциях изменения сути проектного дела в современном обществе. Появилась новая форма синтеза искусств, подключающая к традиционной триаде “архитектура – живопись – скульптура” и другие виды предметного и художественного творчества – от инженерно-технического до сценографии процессов труда и быта (магистерские диссертации А.А. Локотко “Современные тенденции урбодизайна”, рук. А.А. Литвинова, и Л.Г. Бицютко “Произведения пластических видов искусств в пленэре (открытых городских пространствах), рук. А.А. Литвинова, П.В. Войницкий). Синтез на новом уровне мировосприятия всех компонентов нашего окружения подразумевает и новые глубины знания о путях эмоционально-чувственного освоения сложности мира, и новые технологии формирования создаваемой “второй природы”, и ее экологическое единство с естественной природной основой.
Анализ различного рода поискового проектирования в области дизайна архитектурной среды показывает, что оно дает двоякий результат. Во-первых, обогащается номенклатура тем проектирования, указывающая на необходимость и неизбежность появления в нашем окружении новых типов сред, во-вторых, появляется возможность обобщения проектно-исследовательской теории и практики, возможность выявления тенденций архитектурно-дизайнерской деятельности.
Для профессии архитектора и дизайнера созрела объективная и настоятельная потребность в овладении искусством архитектурного дизайна с целью решения разноаспектных архитектурных и дизайнерских задач, которые возникают в процессе проектирования города, его фрагментов, отдельных объектов в комплексе с традиционными задачами создания градостроительной, архитектурной и дизайнерской формы.
Архитектура — Декларативна. Реализация — Императивна. Все остальное — Бюрократия
Что такое Архитектура? Чем Архитектура отличается от Дизайна? Где граница между Архитектурой и Реализацией? Можно ли увидеть Архитектуру? Можно ли тестировать Архитектуру? Чем отличаются Инженерный и Эволюционный подходы к Архитектуре? Что такое Хорошая Архитектура? В чем состоит работа Архитектора? Чем она отличается от работы Разработчика? Какие инструменты доступны Архитектору? Можно ли менять Архитектуру отдельно от Реализации? Есть ли у Архитектуры ДНК?
Изображение из блога tomaszjaniak
Покажите нам вашу Архитектуру
Бывает так, что уже пару лет работаешь на проекте и вот прямо сейчас сидишь по локоть в коде, тесты горят, кулер ноутбука шумит, пытаясь охладить жар перегретого компилятором процессора, вот-вот еще несколько часов — и рефакторинг будет закончен. И тут срочно нужно все бросить и нарисовать Архитектуру проекта. Намечается крупный клиент, и, для того чтобы закрыть сделку, необходимо пройти аудит. А в этом деле без Архитектурных Диаграмм никуда. Ну и что, что проект еще маленький, и дюжине его разработчиков в реальной работе никой Архитектуры там не требовалось. Вот же код — все понятно. Но выхода нет. Надо — значит надо.
Если знаешь, как все устроено, Архитектуру любого продукта можно нарисовать за час. И для прохождения аудита этого обычно достаточно. В конце концов, смысл аудита не в том, чтобы люди со стороны реально разобрались в Архитектуре вашего продукта. Вся суть вопроса в том, чтобы определить, есть ли у самих разработчиков продукта понимание того, что они делают. И если говорить достаточно уверенно и отвечать на вопросы без запинок, все пройдет гладко. Но все же, когда эта история закончится, где-то в глубине поселится червячок, который будет точить вопросом: а все-таки, какая же у продукта Архитектура на самом деле? Ведь, если спрашивают, наверное, у других Архитектура есть. А если у нас нет — это явно непорядок. Возникает большое желание сделать все хорошо, чтобы в следующий раз ответить за Архитектуру как полагается.
Как же сделать все правильно? Нужно нарисовать диаграммы, описать фичи в документах, а потом все это поддерживать в актуальном состоянии. Вот тогда это будет Архитектура. Но, представив объем работ, быстро приходит понимание, что это все не стоит потраченного времени. Вот же код — все понятно. А если придет другой клиент, то еще за час можно будет нарисовать новую диаграмму.
А спустя несколько лет можно оказаться в обратной ситуации, и документы, которые будут описывать архитектуру другого продукта, окажутся ничуть не лучше. Конечно, полезно знать, что у других с Архитектурой тоже все очень плохо. Но когда размер проекта начинает измеряться миллионами строк кода, а количество разработчиков сотнями, вопрос необходимости Архитектуры все же становится значимым.
Тут уже в рамках рабочего процесса начинают появляться различные Архитектурные диаграммы, на фичи начинают писать Архитектурные пропозалы, все это обсуждается, ревьювится, валидируется, аппрувится и, конечно, устаревает еще до того, как эти процессы закончатся. О том, что такие документы отражают реальную структуру кода приложения, и говорить не приходится. А когда дело доходит до реализации, случается что разработчики эти документы вообще не читают. Или реализуется что-то совсем другое, чем было написано. Кто-то кого-то не так понял, или нужно было срочно сделать, и не было времени обсуждать.
Может быть, все так и должно быть. Может быть, Архитектура — это и есть Бюрократия вокруг спекулятивных документов, оторванных от реальности? Но интуиция подсказывает, что все-таки нет. Так что же тогда такое «Архитектура»?
Архитектура это.
Что будет, если задать вопрос «Что такое Архитектура?» десяти профессиональным разработчикам? Если не подглядывать в Википедию, дадут ли они один и тот же ответ?
Архитектура — это и совокупность важнейших решений, и структура элементов, и их интерфейсы, и система положений, правил и договоренностей, и сформированные подходы, удерживающие порядок, и решения глобальных задач, и декомпозиция со взаимодействием, и высокоуровневое описание системы, и жизненный цикл ее частей, и шаблоны структуры и поведения, и то, что сложно или дорого поменять или убрать, и фундаментальные решения и трейд-оффы, и многое другое.
А еще Архитектура — это то, каким образом приложение выполняет свое предназначение.
API — это Архитектура, схема данных — это тоже Архитектура, и структура модулей и сервисов. Есть Архитектура масштабирования приложения, Архитектура его надежности, Архитектура взаимодействия компонент и Архитектура безопасности. И конечно, у каждой фичи есть своя Архитектура. И все это вместе — это тоже Архитектура.
Можно ли считать все это ответом на вопрос «Что такое Архитектура?» — пожалуй, да. Вроде бы все правильно, вроде бы все понятно. Но является ли этот ответ практически полезным, тем, что можно использовать в реальном рабочем процессе? Не совсем.
Как понять, что решение важное или фундаментальное? Что такое глобальные задачи? Что значит дорого или дешево? Как оценить сложность? Где граница между высокоуровневым и низкоуровневым? Что такое порядок? В чем состоит предназначение системы?
Все это вопросы, на которые тоже можно попытаться ответить. Сформулировать определения, пояснить на примерах, на худой конец, организовать процесс принятия решений. Но это все равно останется чем-то спорным, чем-то интуитивным, зависящим от личного восприятия и понимаемым каждым немного по-своему. А значит, всегда будут конфликты, основанные на том, что разные люди трактуют одну и ту же ситуацию кардинально по-разному. Разработчики будут жаловаться, что архитекторы вмешиваются в детали реализации, архитекторы — что разработчики ломают Архитектуру. Если четкой границы нет, конфликты неизбежны.
Некоторое общее понимание того, что такое Архитектура, вероятно, есть у каждого. Но назвать единое, формально выверенное и математически точное определение представляется затруднительным.
С другой стороны, если спросить «Что такое Реализация?» — ответ, вероятно, будет однозначным: «Вот ссылка на репозиторий с кодом!». И ведь с этим не поспоришь. И каких-то сомнений или двусмысленности трактовки этого ответа не возникает. 1+1=2, Реализация — это код.
А с кодом работать очень просто. Если хочется разобраться в реализации — можно открыть проект в среде разработки. Если изменения в коде нужно ревьювить — на то есть ветки в репозитории. Если пришло время релизить новую версию приложения — запускаются тесты.
Конечно, структура проекта может оказаться запутанной, ревью — некачественным, а покрытие тестами — неполным. Но, по крайней мере, работая с кодом, всегда кристально ясно, что и когда нужно делать.
Но что если Архитектура выражалась бы кодом, так же, как и Реализация?
Декларативность и Императивность
В современной разработке используется множество мейнстримных языков программирования. Большинство из них появились давно или очень давно. И несмотря на то, что они все еще хороши, все же они понемногу устаревают. Это слабо типизированные языки: JavaScript, Python, PHP, Ruby, и языки со строгой типизацией: Java, C/Objective-C/C++, C#. Им на смену приходят новые языки, которые в рамках той же платформы пытаются решить застарелые проблемы, посыпая их синтаксическим сахаром, но не внося принципиально новых концепций, если смотреть глобально: Swift, Kotlin, TypeScript, Go. Все это языки, построенные на Объектно-Ориентированной парадигме. Также, зрелую популярность приобрел и Функциональный подход к программированию, который как реализуем на перечисленных языках, так и представлен в языках специализированных, но менее популярных: Erlang, F#. Начинают набирать популярность и языки, реализующие существенно новые концепции: Rust, Haskell.
Все это разнообразие объединяет одно: все это языки Реализации. Ни один из перечисленных языков программирования не является выражением Архитектуры. Но есть одно исключение — SQL.
SQL — это единственный мейнстримный язык программирования, который является Декларативным. Он построен на модели реляционной алгебры и имеет узкую специализацию — работа с хранимыми данными. Но все же, почему SQL можно считать языком Архитектуры?
В первую очередь, SQL дает доступ к мета-информации о схеме данных. По базе данных можно легко получить список таблиц, колонок, связей, индексов, представлений, ролей и прочее. Документация по схеме хранения данных и возможность ее визуализировать — это большое подспорье для понимания структуры приложения. Описание схемы данных — это один из видов высокоуровневого описания Архитектуры.
Во вторых, SQL предоставляет язык запросов к данным, который позволяет клиенту запрашивать любые комбинации данных, описанных в схеме. Если бы языка запросов не было, то на каждую модель данных, требуемую клиенту, пришлось бы либо реализовывать отдельный API метод, либо клиент был бы вынужден выполнить несколько API-вызовов к различным частям схемы данных и скомбинировать требуемую модель на своей стороне. Наличие языка запросов позволяет исключить из описания Архитектуры детали реализации, связанные с перечислением API методов на получение конкретных моделей данных по общей схеме. Язык запросов исключает детали реализации из описания Архитектуры.
SQL предоставляет три ключевых свойства важных для описания Архитектуры:
Другие средства описания Архитектуры
Прямым аналогом SQL является GraphQL, который также позволяет определить схему данных и предоставляет доступ к ней через язык запросов. При этом GraphQL строится на теории графов, а не на модели реляционной алгебры. Это дает возможность работать с иерархическими моделями данных более естественным способом, в отличие от SQL, где работа с иерархиями бывает затруднительной.
GraphQL часто продвигается как решение для клиент-серверного взаимодействия, но это не единственная область его применения. Точно так же через GraphQL можно обеспечить и сервер-сервер взаимодействие, и даже взаимодействие сервер-база. То, что современные базы данных предоставляют только SQL интерфейс, но не дают удобного API для работы с иерархическими запросами — обидное упущение.
Если SQL является средством описания Архитектуры схемы хранения данных, то GraphQL позволяет описать Архитектуры схемы данных уже на бизнес-уровне, в терминах конкретной прикладной области. В этом смысле GraphQL позволяет определить Архитектуру на более высоком уровне, ближе к реальной прикладной области продукта.
Модули кода и микросервисы, совместно с их API и зависимостями, также являются средствами выражения Архитектуры в терминах структуры и связей.
Архитектура и Реализация
Для небольшого проекта, над которым работает десяток разработчиков, какого-то отдельного описания Архитектуры часто не требуется. Если код проекта написан аккуратно и хорошо структурирован, этого может быть вполне достаточно для понимания общей картины и направлений развития.
С ростом проекта появляются различные документы, описывающие как его общую Архитектуру, так и детали новых частей и крупных доработок. Это вполне рабочий подход в случае, когда над проектом работает несколько десятков человек.
Но для достаточно крупного проекта, когда счет разработчиков идет на сотни, такой подход начинает давать сбои. Документов становится слишком много, а их содержание начинает все сильнее расходиться с Реализацией. Становится все труднее выразить мысли одинаково понятным для всех образом. На обсуждение множества частных тем организуются митинги на десятки человек, тогда как действительно важные изменения могут оказаться реализованными вообще без каких либо обсуждений. Все это приводит к к необходимости организации все большего количества процессов, когда одни должны что-либо предлагать, другие следить, третьи ревьювить, четвертые делать. Бюрократия. В результате разработчики начинают писать все больше документов и все меньше кода, и это еще не самая значительная проблема.
Конечно, в Бюрократии как таковой нет ничего плохого. В любой работе важна ее организация. Проблема заключается в количестве Бюрократии на единицу полезной работы. Если для того, чтобы сделать Раз, нужно провести еще Два, Три, Четыре, Пять митингов, — это уже никуда не годится.
Даже простой вопрос, какое изменение разработчик может сделать сам, потому что это Реализация, а по какому нужно сделать запрос на ревью, потому что это Архитектура, — начинает вызывать трудности. Приходится придумывать разнообразные Архитектурные триггеры, что, если вы меняете схему данных или затрагиваете вопросы криптографии и безопасности — это нужно ревьювить Архитектурно, а другие темы вроде бы нет, но это не точно. Все это нужно не только сформулировать и объяснить сотням разработчиков, но и следить за тем, чтобы описанные правила соблюдались. Такой процесс постоянно будет давать сбои.
Все эти проблемы связаны с отсутствием четкого определения Архитектуры.
Так же, как изменение «.java» файла в репозитории однозначно говорит об изменении реализации, изменение «.architecture» файла может говорит об изменении архитектуры. Конечно, «.architecture» файлов в природе не существует. Но для каждого проекта можно определить, какие конкретно его аспекты относятся к его архитектуре, и сделать это явным.
Если изменение схемы данных считается изменением Архитектуры — значит файлы содержащие SQL-миграции должны относится к Архитектуре. Если API — это тоже часть Архитектуры, можно определить API в виде тех же swagger файлов, и полагаться на них. Если структура модулей — Архитектура, тогда изменение описания модулей — это Архитектурное изменение. И так далее.
Не все аспекты Архитектуры могут быть выражены стандартными средствами. Каждый проект имеет свою специфику. Например, если в продукте используется специфичная модель прав, ролей, типов подписок, аддонов и так далее, то стоит задуматься о том, чтобы определить Архитектуру этого аспекта продукта в некоем подходящем Декларативном виде, тем самым выделив суть Архитектуры из деталей Реализации. Конечно, такие изменения могут потребовать существенной переработки кода. Но это существенно лучшая инвестиция в определение Архитектуры продукта, чем попытка описать модель его прав в документе.
Формальное представление Архитектуры в коде возможно, и только оно дает четкое определение того, что такое Архитектура. Такое представление дает возможность анализировать Архитектуру и автоматически генерировать по ней документацию, которая всегда будет актуальной. Все остальные: документы, схемы и диаграммы составленные вручную — Бюрократия.
У Архитектуры может быть формальное выражение в коде, и только оно задает четкую границу между Архитектурой и Реализаций. И такая граница нужна.
Инженерный и Эволюционный подходы в Архитектуре
За последние полвека индустрия разработки прошла длинный путь от waterfall модели к разработке итерациями. И сейчас создается впечатление, что индустрия зашла в этом вопросе уже слишком далеко. Работа архитектора местами уже перестает быть похожей на работу инженера или даже садовника, и все больше начинает походить на труд сезонного рабочего, нанятого с единственной целью — пропалывать грядки от сорняков.
Инженерию от ремесла отличает понимание законов природы, закономерностей, на основании которых можно делать расчеты и выводы, проектировать решения, а не экспериментировать. Любой столяр может изготовить вполне приемлемый табурет, но для того, чтобы табурет получился оптимальным: легким, надежным, устойчивым, простым и дешевым в производстве, нужны инженерные знания. Инженерный подход позволяет получить оптимальный результат быстро и с наименьшими усилиями. К сожалению, в разработке программного обеспечения инженерный подход не всегда возможен.
Часто результат, которого хочется достичь, определяется весьма расплывчато, многие факторы, значительно влияющие на Архитектуру решения, представляются нечетко или вообще неизвестны, а сама работа по Реализации решения может оказаться быстрее и дешевле, чем детальная проработка его Архитектуры. В том числе поэтому итеративный подход к разработке заслужил такую популярность. Иногда даже сверх меры.
В худшем случае проработка Архитектуры может свестись к тому, что каждая команда разработки просто отдает на ревью архитектору некое описание того что они собираются реализовать. В такой ситуации работа архитектора сводится к выпалыванию сорняков. А вот здесь вы не забыли? А вот это учли? А тут неправильно. А здесь не хотите индекс добавить? И так итерация за итерацией.
Пропалывать сорняки необходимо. Но каков будет сад, если заниматься только этим? Цветочные клумбы завянут в тени фруктовых деревьев, клубника и морковь будут расти вперемежку, и все это окажется пересечено бесчисленным количеством тропинок, впустую расходующих доступное пространство. Здесь трудно говорить о какой-либо Архитектуре.
Чтобы Архитектура появилась, архитектор должен выполнять хотя бы работу садовника. Ягоды и овощи стоит растить отдельно — структура, а там, где люди ходят чаще всего, нужно проложить дорожки — связи. Наблюдая за частностями, архитектор может действовать проактивно, организуя и систематизируя в единую структуру частные особенности возникающие в процессе Реализации. Как и ландшафтный дизайн, архитектор может оформлять естественное развитие событий, закрепляя позитивные тенденции и предотвращая негативные.
И тут уже нужно четкое определение Архитектуры в коде. Схемы данных, структуры модулей и сервисов, их API и правила взаимодействия. Без определения этих инструментов архитектор либо погрязнет в ревью реализации, либо будет наивно надеяться, что разработчики действительно будут следовать правилам, описанным в каких-то там документах, чего, конечно же, не случится.
Если есть формальное представление Архитектуры и правила ее изменений, это уже можно назвать Эволюционным подходом к развитию Архитектуры. И это уже неплохо. Но стоит ли этим ограничиваться?
Да, изначально требования могут выглядеть расплывчато, факторы — туманно, а сама система настолько сложной, что проще сделать, чем проектировать. Но со временем эти вещи начинают проясняться. С практическим опытом развития Архитектуры детали организации ее прикладной области представляются все более и более четкими. Становится понятно, что вот это общее решение реализовано пятью разными способами, и что пользователи страдают от такого разнообразия. Что одни вещи не на своем месте и их нужно переместить, а другие уже устарели и заменены новыми решениями, так что их нужно убрать. Да и новые разработки перестают выглядеть такими уж новыми — и это мы уже реализовывали, и то. А помните, к чему все это привело? Давайте сразу сделаем как надо, чтобы потом не переделывать. Ведь сделать сразу правильно обычно бывает быстрее, чем как придется. Но это только если действительно знаешь, как правильно. И с опытом такое понимание часто приходит.
Хорошая Архитектура — это не то, что само по себе выросло и потом было немного организовано, но нечто целостное, симметричное и органичное. Инженерный подход к развитию Архитектуры возможен, просто понимание правил и закономерностей может занять некоторое время.
Формальное определение Архитектуры конкретного проекта не обязательно должно быть статичным. Устаревшие методы API можно объявлять как Deprecated, а недостающие декларировать как Not Implemented. Осмысленные части кода можно отмечать для вынесения в отдельные модули. Можно планировать разделение таблицы на две, или перенос их в другую базу данных. И так далее. Архитектуру можно менять, не меняя реализации. Реализация догонит. А чтобы догоняла быстрее, процесс можно немного автоматизировать, сделав автоматические напоминания в командные чаты. Точно так же, как изменения разработчиков в Архитектурных файлах могут автоматически попадать в чат архитектурной команды.
Инженерный подход к развитию Архитектуры возможен.
При этом не стоит считать, что работа архитектора чем-то принципиально лучше или хуже работы разработчика. Она просто другая. Разработчик, в первую очередь, работает в Императивном стиле, тогда как работа архитектора — больше Декларативная. Бывает, что проработать Архитектуру сложно, а Реализация —- рутина. Бывает и наоборот.
Архитектура и Дизайн
Термины Архитектура и Дизайн часто употребляют как синонимы. Можно сказать: Архитектура системы или Дизайн системы. По большому счету, понятно, о чем речь. Но все же в этих терминах можно найти существенные отличия.
Под Дизайном, прежде всего, понимается нечто визуальное, то, что можно представить или увидеть. Схемы, диаграммы, модели. Дизайн позволяет наглядно показать взаимосвязи между сущностями, проследить цепочки взаимодействия, увидеть структурные различия и аналогии.
Но Архитектура не только визуальна, она может включать в себя правила и ограничения, логические выводы и математические расчеты. Концепции, которые плохо визуализируются.
Конечно, и то, и другое важно.
Хорошо, если важные аспекты архитектуры явным образом определены в коде. Но этого недостаточно. Важно сделать Архитектуру наглядной, а принципы в нее заложенные автоматическими.
Если Архитектура включает в себя схему данных — должно быть и ее визуальное представление. У модулей есть зависимости — их тоже нужно визуализировать. Если есть API — по нему должна быть документация, напрямую связанная со структурой сервисов. И так далее. Дизайн — это визуальное представление Архитектуры.
Если в Архитектуру заложены определенные принципы, например, «клиентские приложения могут обращаться только к определенным типам микросервисов, но не ко всем», то при наличии модели коммуникации их можно проверять автоматически. Точно так же можно контролировать связи микросервисов и баз данных. Если есть определенные правила дизайна моделей данных, те же правила именования таблиц, то и их тоже можно проверять автоматически. В разработке же используются автоматические проверки кода, то же самое можно реализовать и для Архитектуры. На Архитектуру можно писать автотесты.
Заключение
Современному разработчику доступен огромный спектр потрясающих инструментов, делающих его работу проще. Среды разработки, системы сборки, разнообразные библиотеки и фреймворки, инфраструктурные сервисы и контейнеры. Разработчики не пишут код в Notepad.
Архитектура — это тоже код, и для работы с Архитектурой возможен столь же мощный и богатый инструментарий, что и для работы с Реализацией. Google Docs — это не единственно возможный инструмент архитектора и далеко не самый лучший. Конечно, спектр готовых инструментов, доступных архитектору прямо сейчас далеко не столь велик, как спектр инструментов разработчика. И далеко не все, что архитектор потенциально может использовать, работает из коробки. Но все же дела обстоят не так плохо.
Многие инструменты существуют уже десятки лет, например SQL, нужно просто научиться их правильно использовать. Новые технологии, такие как GraphQL, начинают набирать популярность, и они дают надежду на то, что задачи описания бизнес-домена со временем станут столь же рутинными, сколь и описание домена хранения данных. Доступны средства документации и визуализации структуры приложения и API, в том числе Swagger. Для тестирования Архитектуры можно использовать те же фреймворки и инструменты интеграции, что и для тестирования Реализации.
Архитектура — Декларативна. Вероятно, Бюрократия работы с документами никогда полностью не исчезнет из работы архитектора, но уже сейчас ее объем можно существенно сократить. Архитектура — это тоже код, и со временем доступный инструментарий для работы над Архитектурой может стать столь же развитым, как и инструментарий для работы над Реализацией. Посмотрим.