Comments 89
Разработка трехвенки в этом посте очень напоминает руководство по рисованию совы
Рад, что вам понравилось.
К сожалению, есть молодые коллеги, для которых уже вопрос о том, с чего начать проектирование системы, вызывает дрожь. А когда речь идёт об очень сложных системах, оторопь берёт и опытных архитекторов. Хотя суть-то остаётся почти той же, разве что решение бывает несколько хитрее и, вы правы, содержит гораздо больше подсистем, слоёв и уровней.
К сожалению, есть молодые коллеги, для которых уже вопрос о том, с чего начать проектирование системы, вызывает дрожь. А когда речь идёт об очень сложных системах, оторопь берёт и опытных архитекторов. Хотя суть-то остаётся почти той же, разве что решение бывает несколько хитрее и, вы правы, содержит гораздо больше подсистем, слоёв и уровней.
grossws вероятно имел в виду туториал по рисованию совы в стиле «нарисуйте 2 овала, дорисуйте остальную сову» (пример). Скорее всего он намекает, что «как рисовать остальную сову» тем самым новичкам совершенно непонятно. Архитектуру нельзя объяснить на пальцах, нужна более подробная статья. Вероятно даже цикл статей с поэтапным «рисованием совы».
Не согласен. Поэтапное рисование совы архитектуры можно найти, в том числе в Руководстве Microsoft, предлагаемом в конце статьи.
Но есть нюанс: в руководствах пропущен самый первый шаг. Остаётся открытым вопрос, как же начать проектировать систему. Я даю простой приём, который применим для любой системы и в любой нотации: начать от внешних систем и пользователей и постепенно углубляться внутрь.
Нотацию для своего примера я выбрал ту, которая, по моему опыту, наиболее понятна новичкам. Но тот же подход можно применить, рисуя схему в EnterpriseArchitect с использованием Archimate. Только объяснять условные обозначения придётся долго.
Так что с точки зрения методологии тут всё в порядке. Не надо отбрасывать последний абзац.
Но есть нюанс: в руководствах пропущен самый первый шаг. Остаётся открытым вопрос, как же начать проектировать систему. Я даю простой приём, который применим для любой системы и в любой нотации: начать от внешних систем и пользователей и постепенно углубляться внутрь.
Нотацию для своего примера я выбрал ту, которая, по моему опыту, наиболее понятна новичкам. Но тот же подход можно применить, рисуя схему в EnterpriseArchitect с использованием Archimate. Только объяснять условные обозначения придётся долго.
Так что с точки зрения методологии тут всё в порядке. Не надо отбрасывать последний абзац.
К сожалению, есть молодые коллеги, для которых уже вопрос о том, с чего начать проектирование системы, вызывает дрожь. А когда речь идёт об очень сложных системах, оторопь берёт и опытных архитекторов.Т.е. вы предлагаете психотерапевтический приём, предназначенный для того, чтобы успокоиться и перестать дрожать? Ну тогда да, возможно кому-то и будет полезно. Потому что к разработке архитектуры это, уж извините, не имеет отношения.
Интересно, а паттерн MVC по-вашему имеет отношение к разработке архитектуры?
Разумеется имеет (равно как и трёхзвенная архитектура). Но это не единственное возможное решение. И разработка архитектуры как раз и заключается в том, чтобы из всего спектра возможных решение выбрать наиболее подходящее в конкретном случае. И именно об этом в данной статье ничего и не сказано — а сказано только, как нарисовать красивую картинку для одного из вариантов решений.
Судя по последнему абзацу так и было задумано.
При этом даже выбор именно трёхзвенки желательно обосновать. Да, это очень частое решение, но всё же не всегда самое лучшее — а иногда и откровенно вредное.
Кстати, книга находится в свободном доступе на сайте Microsoft: «Руководство Microsoft по проектированию архитектуры приложений»
Выясните [...] к чему будет обращаться Ваша программа. [...] Те, к которым будет обращаться программа (включая БД), — снизу.
У кого выяснять, к чему будет обращаться программа? Если вдруг БД — то какая?
Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.
А если мы обращаемся не к данным, а ко внешним сервисам — все равно слой доступа к данным?
Иногда UI тоже может обращаться к API.
И как решить, у нас это «иногда», или другое «иногда»?
В маленьких прямоугольниках внутри этого контура перечислите основные бизнес-задачи. Один компонент Вашей системы будет решать одну бизнес-задачу.
Вообще-то, декомпоновка предметной области на задачи, и их последующее размещение по компонентам — это задача, требующая немалого опыта. Откуда в вашем случае берется список бизнес-задач? Почему вы считаете, что они соотносятся с компонентами 1-к-1?
Ну да, а еще вы совершенно не учитываете, что секционирование может быть не только по слоям, но и по областям (а у вас, скажем, один слой БД на всю бизнес-логику), что бывает SOA и микросервисная архитектура, ну и так далее.
Но самое-то грустное не в этом. Самое грустное в том, что из вашей схемы совершенно не понятно, что именно в реальности надо делать. Она бессмысленна — в том смысле, что не несет никакого дополнительного понимания, как и сотни подобных схем, кочующих по современным (точнее, слегка устаревшим) пафосным ТЗ.
Вот казалось бы, простой вопрос: почему UI и «сервисный слой» — на веб-кластере (причем одном на всех), а бизнес-логика и слой доступа данных — на «сервере приложений». Там масштабирование не нужно, что ли? А как организовано общение между сервисным слоем и сервером приложений? А как именно организован мониторинг?
Но самое-то грустное не в этом. Самое грустное в том, что из вашей схемы совершенно не понятно, что именно в реальности надо делать. Она бессмысленна
Пожалуй, комментарии в духе «статья плохая, потому что после прочтения у меня остались вопросы или я что-то не понял» являются очень распространенными на хабре. Если есть вопросы, то можно загуглить, скачать книгу, спросить у автора. Но зачем критиковать? Чтобы полностью осветить все вопросы по проектированию, нужна не одна книга. А это просто статья. И она вполне могла бы быть первой главой в какой-нибудь книге. Она задаёт общее направление для рассуждений, упорядочивает мысли и заинтересовывает читателя в процессе проектирования. Разве этого мало?
Мало, как правильно указали выше, результатом статьи стало что-то, что назвали «красивой схемой архитектуры». По факту это просто орнаменты по мотивам визио, которые красиво смотрятся в презентации заказчикам из не-IT сферы, но не тянут на громкий заголовок.
Но зачем критиковать?
Чтобы стало лучше, очевидно.
Если есть вопросы, то можно загуглить, скачать книгу, спросить у автора.
Понимаете, это у меня есть эти вопросы, потому что я и так имею представление о процессе проектирования. А откуда они возьмутся у человека, который в ней ничего не понимает? Ну и да, если загуглить и скачать книгу, то можно и вообще без этой статьи обойтись.
Она задаёт общее направление для рассуждений, упорядочивает мысли
А правильное ли это направление? Я вот совершенно не уверен: в статье пропущено достаточно моментов, которые обязательно должны быть оговорены даже в «первой главе».
заинтересовывает читателя в процессе проектирования.
А зачем? Обычно к книгам по архитектуре приходят люди, которые и так знают, зачем им это надо. А тех, кто не знает. может, лучше и не заинтересовывать?
Собственно, вопрос «зачем» — он, как всегда, ключевой. Для чего предназначена схема, разработанная в статье (поверьте мне, ответ на этот вопрос далеко не однозначен)? Для кого и для чего предназначена сама статья?
А зачем? Обычно к книгам по архитектуре приходят люди, которые и так знают, зачем им это надо. А тех, кто не знает. может, лучше и не заинтересовывать?
Не совсем так. Жизнь сложнее. Вот простой пример, когда спроектировать систему нужно (например, руководство отдало приказ программисту), а знаний не достаточно. На то, чтобы читать книги и аккуратно всё применять на практике, времени в этом случае нет. И что парню в этом случае делать? Ему архитектура, может, и не интересна, но работу надо делать. А Вы, вместо того, чтобы ему помочь, предлагаете ему пойти подальше. Нехорошо. Я предложил свой путь решения: быстро набросать схему и воспользоваться Руководством MS, написанным в виде справочника (т.е. не обязательно его читать с самого начала). Методологически моё решение закончено.
Если у Вас есть своё решение, предложите его.
Вот простой пример, когда спроектировать систему нужно (например, руководство отдало приказ программисту), а знаний не достаточно. На то, чтобы читать книги и аккуратно всё применять на практике, времени в этом случае нет.
Эээ… отдавать проектировать систему человеку, у которого для этого недостаточно знаний? И нет времени на самообучение?
А Вы, вместо того, чтобы ему помочь, предлагаете ему пойти подальше.
Я предлагаю ему пойти поучиться.
Если у Вас есть своё решение, предложите его.
Я стараюсь не решать flawed problems. Если вы ставите задачу человеку, у которого недостаточно квалификации, ему нужно пойти поучиться. Если у него нет и этой возможности, ему не надо решать эту задачу.
Следуя вашей методологии он, скорее всего, совершит нездоровое количество ошибок, которые впоследствии отразятся на всем проекте.
Отдавать проектировать систему человеку, у которого для этого недостаточно знаний? И нет времени на самообучение?
lair, если подходить к вопросу академически, Вы правы. Но реальность, как всегда, шире и глубже.
Вот пришёл ко мне юный архитектор, вроде как образование профильное и всё такое. Но на практике с разработкой архитектуры он в вузе не сталкивался. Что, снова его послать учить? Не работает. Надо натаскивать на практику в боевых условиях. Мой подход в этом случае работает и помогает человеку быстро войти в работу. Уже через пару часов у него есть первый макет архитектуры, и можно с ним говорить о более глубоких деталях.
А в соседнем отделе начальство… дало программисту (даже не ведущему) проектировать систему. Приходит ко мне, типа «как быть». Что, послать его учиться? Да его уволят, хотя, заметьте, не он виноват. Поэтому я даю ему маленький толчок, как начать работу. И дальше он может работать со справочниками типа того же Руководства MS, и задавать вопросы мне, Вам или кому-то ещё из опытных коллег. Это работает. А когда цейтнот спадёт, тогда уже можно послать парня учиться.
Вот пришёл ко мне юный архитектор, вроде как образование профильное и всё такое. Но на практике с разработкой архитектуры он в вузе не сталкивался.
Значит, он не архитектор.
Не работает.
Почему же?
А в соседнем отделе начальство… дало программисту (даже не ведущему) проектировать систему. Приходит ко мне, типа «как быть». Что, послать его учиться? Да его уволят, хотя, заметьте, не он виноват.
Почему уволят-то? Должностные обязанности нарушил? А откуда у него в должностных обязанностях проектирование?
Я не знаю, что вы рассказываете людям, которые приходят к вам, но то, что вы пишете в обсуждаемой статье — это толчок в неправильном направлении. Начинать надо с определения задач, а потом — minimum viable architecture. А вы сразу рисуете монстра. Зачем?
Она задаёт общее направление для рассуждений, упорядочивает мысли и заинтересовывает читателя в процессе проектирования. Разве этого мало?
Лучше вообще не учить, чем учить в корне неправильно. Проблема в частности интернета в том что зачастую школьник, мельком прочитавший книгу для чайников (написанную тоже невеликим гуру), тут же считает себя экспертом и начинает всех подряд учить, в результате учат непонятно чему непонятно зачем. Другой школьник пересказывает уже его статьи и получается такой испорченный телефон дилетантов.
UFO just landed and posted this here
Глядя на конечную схему, сразу вспоминается астронавт архитектуры. Архитектура это компромисс между требованиями и имеющимся ресурсами, т.е. вся эта красивая архитектура может не уложиться в бюджет и сроки.
От tutorial'а для молодых коллег ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.
От tutorial'а для молодых коллег ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.
ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система
Если Вам нужно такое подробное руководство, то ссылка на него приведена в конце статьи. Почитайте.
Где-то есть руководство, в котором описаны задачи, которые решает система, которую я проектирую?
Вопрос RPG18 был о руководстве для для молодых архитекторов, а не о руководстве к Вашей собственной системе. Вы невнимательны.
Разве?
(выделение мое)
ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.
(выделение мое)
От tutorial'а для молодых коллег ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.
Это полная цитата. Так что вопрос переадресуйте автору комментария.
Ну так все правильно: в туториале должно быть четко сформулировано, как и откуда это все берется. У вас этого нет.
lair правильно понимает. Нужно определить круг задач, которые будет решать будущая система. А без требований к системе, не понятно, откуда появились:
Не могут позволить сайт, но могут позволить себе отказоустойчивый кластер?
- две базы;
- мобильное приложение;
- система справочной информации;
- информационная система Департамента образования;
- отказоустойчивый кластер.
Оба пользовательских интерфейса предназначены для школ, которые не могут себе позволить разработку своего собственного сайта.
Не могут позволить сайт, но могут позволить себе отказоустойчивый кластер?
Да уж. Четко сформулированые задачи сделали бы нашу жизнь гораздо проще. Однако мы не в плановой экономике живем, а при каком-то виде более-менее свободного рынка. А рынок — штука изменчивая и выживает тот, кто лучше адаптируется.
Это касается людей, организаций и даже систем.
С одной стороны чем меньше мы делаем допущений — тем меньше тратим впустую ресурсов. Но при недостаке фактических данных (а будущее никто не знает), допущения делать приходится. Остается делать допущения, которые будут верны с большей вероятностью или которые будут стоить меньше ресурсов.
То, что сделал автор статьи — это несколько допущений, которые потратили впустую ресурсы и впридачу еще и наверняка не верны в рамках задачи.
Хороший пример того, как делать не надо.
Это касается людей, организаций и даже систем.
С одной стороны чем меньше мы делаем допущений — тем меньше тратим впустую ресурсов. Но при недостаке фактических данных (а будущее никто не знает), допущения делать приходится. Остается делать допущения, которые будут верны с большей вероятностью или которые будут стоить меньше ресурсов.
То, что сделал автор статьи — это несколько допущений, которые потратили впустую ресурсы и впридачу еще и наверняка не верны в рамках задачи.
Хороший пример того, как делать не надо.
Я правильно понял, что на этой схеме написано «это вебсервис онлайн-дневника, где журналирование, конфигурация и безопасность побоку»?
Скорее, это просто сквозная функциональность, которая может требоваться на всех слоях. Она на таких схемах обычно рисуется сбоку.
Если из архитектуры потом вырастает проект, то это становится тождественным.
Вы не могли бы пояснить, что имеете ввиду?
То, что безопасность находится именно «сбоку» без явных связей с другими модулями, и никто потом толком не знает, как её пристроить в получившееся огромное приложение, чтобы по возможности охватить как можно больше потенциально проблемных мест. В принципе уже на этапе построения архитектуры не мешало бы прорисовать возможных «врагов» по векторам атаки и частично модули безопасности. Например, в этой схеме к WebUI наряду с пользователем можно дорисовать вредного хакера (сканирование портов на сервере, проба разных эксплоитов, CSRF и т. п), между пользователем и WebUI пристроить MitM, а к WebUI сразу дорисовать модуль аудита безопасности. Это позволит при детальной проработке учесть эти моменты в технических и функциональных требованиях к тем или иным модулям.
А нельзя ли при детальной проработке упомянутые Вами моменты и добавить? Не это ли называется детальным проектированием? А представленная схема является лишь описанием высокоуровневой архитектуры. И она явно не единственная, о чем автор, к сожалению, явно не упомянул
Согласен, какие-то моменты относительно безопасности, например, могли бы появиться и на этой схеме. Особенно, если они архитектурно важны. Но если отметить на этой схеме все нюансы безопасности, то остальные элементы системы на этом фоне померкнут. А насколько я понимаю, высокоуровневое описание архитектуры предназначено для того, чтобы согласовать общее «архитектурное видение» системы со всеми участниками проекта, среди которых могут быть специалисты разного профиля.
Согласен, какие-то моменты относительно безопасности, например, могли бы появиться и на этой схеме. Особенно, если они архитектурно важны. Но если отметить на этой схеме все нюансы безопасности, то остальные элементы системы на этом фоне померкнут. А насколько я понимаю, высокоуровневое описание архитектуры предназначено для того, чтобы согласовать общее «архитектурное видение» системы со всеми участниками проекта, среди которых могут быть специалисты разного профиля.
Лишь в части. На общем уровне проектируется, что делаем, а на детальном — как. Решили в целях безопасности журналить — рисуем журналирование, а на детальном проектировании уже писать, какие данные журналировать, откуда их брать и куда писать. Решили делать резервное копирование — нарисовали модуль; связи (что копируем, куда и как) будем рассматривать на детальном уровне. Решили делать https — рисуем, а на детальном уровне определяемся, где и как реализовывать.
Побоку — потому что сбоку нарисовано?
Нет, не побоку, а сбоку. Сквозная функциональность пронизывает все слои логической архитектуры, поэтому в выбранной нотации их рисуют вертикально, а чтобы схема была читаемой, сдвигают вправо.
Безопасность — это не совсем функциональность. Если сначала все сделать, а потом посмотреть, что осталась нереализована «безопасность», то наверное, уже довольно поздно что-то делать. Это то, что нужно держать в уме для каждой строки кода. То же с журналированием. Зачем оно сквозное и что оно будет журналировать, куда оно будет журналировать на каждом слое архитектуры? lubezniy правильно сказал, что на практике вся эта функциональность будет не сквозная, а побоку. Если же подразумевается, что это само собой разумеющиеся вещи, то зачем оно на схеме? Так можно и «безглючность», «красивый код», «стабильность» туда поместить имхо.
Сразу вспомнился вот этот топик на тостере от того же автора
Архитектуру нельзя описать руководством. Каждый проект это уникальное явление и каждая команда тоже уникальна. Архитектура гораздо шире технических аспектов, это договоренность между всеми участниками проекта. На паттерны, языки, фреймворки и т.п оказывает влияение не только т.з, но и сроки, бюджет, в конце концов скилы команды.
К чему это я? Ах да, не существует руководств типа «Делать вот так, шаг за шагом», многие книги это сборники советов.
К чему это я? Ах да, не существует руководств типа «Делать вот так, шаг за шагом», многие книги это сборники советов.
Кстати, SEI, пожалуй, единственные, кто пытаются стандартизировать подходы в проектировании систем (вернее, пытаются-то не единственные, но единственные, кто преуспели). Достаточно действенен тот же самый Quality Attribute Workshop, который позволяет в сжатые сроки сдоить с холдеров дополнительные критерии.
Архитектуру надо придумывать только тогда, когда продукт рефакторится. До этого создавать самое простое, что возможно; обвешивать датчиками (измерять все что можно) и по необходимости оптимизировать узкие места, покрывать все тестами и чистить код и инфраструктуру от пахнущих кусков.
Многократно сталкивался с архитектурой в waterfall стиле. Ни разу не работало так, как нужно бизнесу в первых двух-трех крупных версиях.
Многократно сталкивался с архитектурой в waterfall стиле. Ни разу не работало так, как нужно бизнесу в первых двух-трех крупных версиях.
Поддерживаю.
Архитектуру нужно ДОКУМЕНТИРОВАТЬ тогда, когда в разработке учавствует больше 1-го человека. Если ее пишет один человек, нет проблем — у него в голове и патерны и фреймворки, и структура БД. Документ это прежде всего средство коммуникации.
Не согласен. Архитектуру надо документировать даже, если в проекте один человек, но продукт предполагает длительное использование и может развиваться в будущем. Человек уйдёт с проекта и забудет о нём. Как восстанавливать причины всех принятых решений, если потребуется через год что-то добавить? Пролезть по всему коду? Это будет значительно дороже, чем сделать сразу нормальное, пусть и не формальное, описание архитектуры.
Обычно код описывает все значительно точнее. Если из кода непонятно, что происходит, то и документация наверное мало поможет.
Смотря какой код (вернее, смотря насколько он сложнее Hello World) и какая документация. Скажем, при наличии прорисованной в виде отдельного документа схемы взаимодействия модулей искать местоположение каких-либо багов в существующей большой системе гораздо проще, особенно человеку, который только входит в этот проект.
Вы пытаетесь убедить архитектора в том, что то, что он делает — не нужно. Я не думаю, что вам удастся.
Почему не нужно-то? Вы считаете, что работа архитектора состоит в написании документации?
1) Я не считаю работу архитектора не нужной.
2) Я не считаю что работа архитектора — это написание документации (впрочем это одна из вещей которой архитектор занимается в рабочее время, как и многие другие роли в SDLC)
Я считаю что объяснять архитектору то, что его работа не нужна — бессмысленно.
1) Это не так
2) Если даже так (не все архитекторы одинаково полезны), то вы не собеседника-архитектора не убедите
3) Даже если убедите — он не признается, что согласен
4) Если признается, то он уже не архитектор и тогда см п2
2) Я не считаю что работа архитектора — это написание документации (впрочем это одна из вещей которой архитектор занимается в рабочее время, как и многие другие роли в SDLC)
Я считаю что объяснять архитектору то, что его работа не нужна — бессмысленно.
1) Это не так
2) Если даже так (не все архитекторы одинаково полезны), то вы не собеседника-архитектора не убедите
3) Даже если убедите — он не признается, что согласен
4) Если признается, то он уже не архитектор и тогда см п2
1) Я не считаю работу архитектора не нужной.
2) Я не считаю что работа архитектора — это написание документации (впрочем это одна из вещей которой архитектор занимается в рабочее время, как и многие другие роли в SDLC)
Тогда я не понимаю, почему вы считаете, что в этой дискуссии кто-то пытается убедить архитектора в том, что то, что он делает — не нужо.
Архитектуру надо придумывать только тогда, когда продукт рефакторится.
Её нужно начинать продумывать уже на стадии формирования концепции продукта. Даже для гибкой методологии это необходимость. При рефакторинге адекватное описание архитектуры поможет быстро найти точки вмешательства.
До этого создавать самое простое, что возможно; обвешивать датчиками (измерять все что можно) и по необходимости оптимизировать узкие места, покрывать все тестами и чистить код и инфраструктуру от пахнущих кусков.
Ранняя разработка архитектуры нужна, прежде всего, чтобы избежать масштабных циклов тестирования — исправления ошибок в конце спринта. Если же архитектуру и детальное проектирование не проводить, то команда заплатит очень дорого за ошибки, которые можно было легко устранить на ранних стадиях, когда неверные решения ещё не были облеплены слоями кода.
Как говорил Макконнелл:
«Тестирование представляет собой способ определения уровня качества программного продукта, а не способ его обеспечения.»
И ещё цитата из Руководства Microsoft, указанного в конце статьи:
«Важно, особенно при проектировании и разработке по гибкому процессу, чтобы итерация включала как проектирование архитектуры, так и разработку реализации. Это поможет избежать масштабного проектирования наперёд.»
Можете поподробнее объяснить откуда возьмутся масштабные циклы тестирования в спринте, если в нем делали все согласно KISS & DRY?
Плюс интересует каким образом архитектура, придуманая на стадии концепции (когда не известно ни поведение системы под нагрузкой, ни собтсвенно сам характер нагрузки) поможет чего-то избежать. Не могли бы вы объяснить, Максим?
Заранее спасибо.
Плюс интересует каким образом архитектура, придуманая на стадии концепции (когда не известно ни поведение системы под нагрузкой, ни собтсвенно сам характер нагрузки) поможет чего-то избежать. Не могли бы вы объяснить, Максим?
Заранее спасибо.
boblenin, не надо передёргивать. Я сказал, что архитектуру «нужно начинать продумывать уже на стадии формирования концепции продукта.» Но не сказал, что на стадии концепции работа над архитектурой заканчивается. Основная работа проводится, когда основные функциональные требования становятся известны. Как было указано в приведённой мной выше цитате, «важно, особенно при проектировании и разработке по гибкому процессу, чтобы итерация включала как проектирование архитектуры, так и разработку реализации». И это — на каждой итерации.
Спринт одной системы отличается от спринта другой системы. В том числе и по масштабу. Всё, что выполнено в рамках спринта, должно быть проверено. Если количество нового/изменённого кода было много или/и были затронуты многие компоненты, тестирование может быть весьма серьёзной задачей. Проще и дешевле подумать до того, как отрезать, чем пытаться пришить отрезанное.
И ещё раз, тестирование — это подход к контролю качества, а не способ его обеспечения.
Пожалуйста.
Спринт одной системы отличается от спринта другой системы. В том числе и по масштабу. Всё, что выполнено в рамках спринта, должно быть проверено. Если количество нового/изменённого кода было много или/и были затронуты многие компоненты, тестирование может быть весьма серьёзной задачей. Проще и дешевле подумать до того, как отрезать, чем пытаться пришить отрезанное.
И ещё раз, тестирование — это подход к контролю качества, а не способ его обеспечения.
Пожалуйста.
> Я сказал, что архитектуру нужно начинать продумывать уже на стадии формирования концепции продукта.
> Основная работа проводится, когда основные функциональные требования становятся известны.
Ну если так — прошу прощения, за взаимное недопонимание. С такой постановкой вопроса спорить глупо.
> Спринт одной системы отличается от спринта другой системы. В том числе и по масштабу.
Безусловно. И размер комманды (в широком смысле) тоже отличается, остаются пропорции. И сохранение пропорций в какой-то мере позволяет говорить о количестве функционала в системах в рамках спринта используя схожие допущения.
Системы, где архитектура развивается отвечая вызовам реального мира в противовес подходу — сначала все спроектируем, а потом будем 10 спринтов строить согласно начальной архитектуре, гораздо проще и с точки зрения разработки и с точки зрения тестирования.
> И ещё раз, тестирование — это подход к контролю качества, а не способ его обеспечения.
Разумеется. Но при чем здесь архитектура?
> Основная работа проводится, когда основные функциональные требования становятся известны.
Ну если так — прошу прощения, за взаимное недопонимание. С такой постановкой вопроса спорить глупо.
> Спринт одной системы отличается от спринта другой системы. В том числе и по масштабу.
Безусловно. И размер комманды (в широком смысле) тоже отличается, остаются пропорции. И сохранение пропорций в какой-то мере позволяет говорить о количестве функционала в системах в рамках спринта используя схожие допущения.
Системы, где архитектура развивается отвечая вызовам реального мира в противовес подходу — сначала все спроектируем, а потом будем 10 спринтов строить согласно начальной архитектуре, гораздо проще и с точки зрения разработки и с точки зрения тестирования.
> И ещё раз, тестирование — это подход к контролю качества, а не способ его обеспечения.
Разумеется. Но при чем здесь архитектура?
Эм,
Вы, надеюсь, не серьезно? Вообще-то поведение системы под нагрузкой является как раз одним из входных параметров, при проектировании систем, а не «потом сбоку докрутим, чтобы не лагало».
Плюс интересует каким образом архитектура, придуманая на стадии концепции (когда не известно ни поведение системы под нагрузкой, ни собтсвенно сам характер нагрузки) поможет чего-то избежать
Вы, надеюсь, не серьезно? Вообще-то поведение системы под нагрузкой является как раз одним из входных параметров, при проектировании систем, а не «потом сбоку докрутим, чтобы не лагало».
> Вы, надеюсь, не серьезно? Вообще-то поведение системы под нагрузкой является как раз одним из входных параметров, при
> проектировании систем, а не «потом сбоку докрутим, чтобы не лагало».
Совершенно верно. Для этого даже термин (паттерн) придуман.
> проектировании систем, а не «потом сбоку докрутим, чтобы не лагало».
Совершенно верно. Для этого даже термин (паттерн) придуман.
Этот паттерн совершенно не про архитектуру, а про оптимизацию КОДА.
Я конечно понимаю, что глупо будет попытаться вас переубедить, но вот к примеру википедия с вами не согласна. en.wikipedia.org/wiki/Program_optimization
И да. Если вы считаете что паттерны и антипаттерны — это о том как правильно кодировать, то это вполне себе ваше право.
И да. Если вы считаете что паттерны и антипаттерны — это о том как правильно кодировать, то это вполне себе ваше право.
Я правильно понимаю, что вы считаете, что можно разработать архитектуру даже не зная примерно ожидаемой на систему нагрузки?
Я разработал достаточно систем, чтобы знать, что ожидаемая нагрузка практически никогда не совпадает с тем, что реально происходит. Систему нужно изучать — для этого надо не гадать, а обвешивать все хуками и софтом для мониторинга, логами и тд. Примерно ожидаемая нагрузка — это гадание. Recipe for disaster.
Те, места которые кажутся потенциально узкими в начале разработки и даже на более поздних этапах далеко не всегда таковыми являются в продакшене.
Мне доводилось работать с приличным количеством систем, где разработчики и архитекторы оптимизировали систему на ранних этапах (кэширование не в правильных местах, параллелизация там где не нужно, да много чего) и все эти «оптимизации» превращались в костыли, которые портили жизнь всем до тех пор пока их не выпиливали.
Те, места которые кажутся потенциально узкими в начале разработки и даже на более поздних этапах далеко не всегда таковыми являются в продакшене.
Мне доводилось работать с приличным количеством систем, где разработчики и архитекторы оптимизировали систему на ранних этапах (кэширование не в правильных местах, параллелизация там где не нужно, да много чего) и все эти «оптимизации» превращались в костыли, которые портили жизнь всем до тех пор пока их не выпиливали.
А когда нагрузка заранее не известна (есть идея, по которой ещё не понятно, «выстрелит» она или нет, или «выстрелит» частично)? Бывает на старте: создаётся новый проект, по которому ещё нет данных по предполагаемому спросу (рынок не сформирован), и после реализации проекта предстоит провести определённую работу по раскрутке бизнеса с неизвестным результатом. Чем больше наплодишь в архитектуре (масштабирование, резервирование, etc), тем больше заказчик потеряет денег и времени в случае неудачи. С другой стороны, какой-нибудь программист Вася за копейки склепает прототип на старт, что помещается на одном сервере или даже виртуалке; а тут проект «выстреливает», и начинаются траблы с прототипом, т. к. архитектура толком не продумана и не документирована.
Я не говорю, что стоить сразу писать приложение с учетом нагрузки как у гугла или фейсбука и пихать везде мезос, но в современном мире существует достаточно много паттернов проектирования, сводящих необходимость переписывания или овер-инжениринга к минимуму. Те же SOA/Microservices не требуют дополнительных усилий, но позволяют заранее застраховаться от многих проблем в будущем.
На тему прототипа, прототип — это прототип. Никто в здравом уме не будет допиливать продукт, который склепал Вася, а оставят его как паблик альфу и сбоку с нуля построят нормальное решение. Но прототип, MVP, PoC или как хотите его назовите — это не более, чем оценка интереса таргет аудитории, а никак не «болванка» для системы, которая пойдет в продакшн. ОК, возможно какой-нибудь сайт на вордпресе и можно дотянуть из прототипа, но в контексте статьи мы говорим о системах с более высокой сложностью.
На тему прототипа, прототип — это прототип. Никто в здравом уме не будет допиливать продукт, который склепал Вася, а оставят его как паблик альфу и сбоку с нуля построят нормальное решение. Но прототип, MVP, PoC или как хотите его назовите — это не более, чем оценка интереса таргет аудитории, а никак не «болванка» для системы, которая пойдет в продакшн. ОК, возможно какой-нибудь сайт на вордпресе и можно дотянуть из прототипа, но в контексте статьи мы говорим о системах с более высокой сложностью.
Кстати вот SOA/Microservices — создают достаточно приличные накладные рассходы (на разработку, инфраструктуру, тестирование и тд), особенно когда их лепят не к месту.
Никто в здравом уме не будет допиливать продукт, который склепал Вася, а оставят его как паблик альфу и сбоку с нуля построят нормальное решение.
К сожалению, «в жизни» это не обязательно так. За последние два года я видел три прототипа, которые потребовали запустить в проде.
И так бывает. И на мой взгляд это не худший вариант. На прототипе можно жить некоторое время, изучая пользователей, подпирая костылями то что падает — покупая время для следующей версии.
Гораздо хуже, когда на этапе прототипирования сделали супер-пупер комбайн, который с помощью конфигурационного файла превращается из CMS в распределенную peer-to-peer базу данных, но при этом бизнесс не взлетел и все нужно выбрасывать.
Гораздо хуже, когда на этапе прототипирования сделали супер-пупер комбайн, который с помощью конфигурационного файла превращается из CMS в распределенную peer-to-peer базу данных, но при этом бизнесс не взлетел и все нужно выбрасывать.
проект системы контроля успеваемости для средней школы. Возьму её по двум причинам. Во-первых, все мы учились в школе. Во-вторых, у многих из нас дети сейчас учатся в той же школе. Из-за этого, надеюсь, предметная область будет всем понятна.
Понятно будет со стороны родителя и то не всякого.
а со стороны учителя, завуча — директора, роно и т.д. предметная область вам понятна?
Предметная область с их точки зрения возможно видится по другому.
Вы предлагаете проектировать архитектуру не имея сформулированных требований к системе. Как следствие вы сразу предлагаете трех звенку и не рассматриваете альтернативы.
С моей точки зрения, для системы контроля успеваемости всю бизнес логику можно засунуть в БД на уровень хранимых процедур.
Боюсь что когда архитектура создается малой кровью, большая кровь появляется на этапе реализации и сопровождения.
Цель статьи — не разработка электронного дневника. Её цель — показать, с чего и как можно начать проектировать систему. Соответственно, пример, приведённый в статье, — всего лишь иллюстрация. Если бы я начал погружаться в детали, потерялась бы основная идея.
Если вас волнует вопрос о концепции самого дневника, предметной областью я владею с разных сторон. Бизнес-логику в БД в данном случае засунуть не удастся.
Если подходить академически к вопросу, то согласен полностью. Но если со стороны реальности, то получается «как всегда», увы. И эта ситуация не всегда зависит от нас. Хотя да, архитектору надо стремиться к самосовершенствованию и быстро переходить из стадии выживания в стадию стабильного развития.
Если вас волнует вопрос о концепции самого дневника, предметной областью я владею с разных сторон. Бизнес-логику в БД в данном случае засунуть не удастся.
когда архитектура создается малой кровью, большая кровь появляется на этапе реализации и сопровождения.
Если подходить академически к вопросу, то согласен полностью. Но если со стороны реальности, то получается «как всегда», увы. И эта ситуация не всегда зависит от нас. Хотя да, архитектору надо стремиться к самосовершенствованию и быстро переходить из стадии выживания в стадию стабильного развития.
Бизнес-логику в БД в данном случае засунуть не удастся.
Почему я должен в данном вопросе верить вам на слово? хотя вы возможно и правы, я предметной областью не владею. Нужны очень серьезные доводы, которых без сформулированных требований к системе не может быть.
А в чем смысл засовывать бизнес-логику в БД? Какие в этом плюсы?
Сам смысл базы данных в том, что она должна хранить данные, а не реализовывать бизнес логику.
Сам смысл базы данных в том, что она должна хранить данные, а не реализовывать бизнес логику.
Все зависит от задачи, есть ИС ( сложнее школьного дневника ), в которых бизнес логика реализована на уровне хранимых процедур и триггеров.
Зачем тогда существуют хранимые процедуры?
Зачем тогда существуют хранимые процедуры?
Хранимые процедуры позволяют логику обработки данных держать вместе с данными. Это очень актуально для DWH (OLAP) сценариев. Для OLTP, когда правила обработки транзакций меняются чаще, чем данные, использовать хранимки скорее невыгодно.
Ну, как минимум, это наследие двух-звенной клиент-серверной архитектуры, когда кроме как в хранимках, серверную бизнес-логику разместить было негде.
В случае с трех-звенкой какой смысл использовать хранимые процедуры, а не реализовывать бизнес-логику на сервере приложений?
В случае с трех-звенкой какой смысл использовать хранимые процедуры, а не реализовывать бизнес-логику на сервере приложений?
Один из полезных сценариев применения хранимых процедур — это уменьшение нагрузки на канал связи с БД.
Другой — это сокрытие реализации, хотя в этом случае лучше другие способы.
Другой — это сокрытие реализации, хотя в этом случае лучше другие способы.
Проектировать систему обычно начинают с разработки BRD и FSD, на основании которых уже и создается архитектура
Статья ни о чем. Я верю, что вы прочитали руководство MS по рисованию квадратиков, но ваша попытка передать «краткое содержание» не удалась.
Любой архитектор, глядя на любую схему, должен найти конкретный (инвариантный, понимаемый всеми одинаково) ответ на два вопроса:
1) Что означают стрелочки
2) Что означают квадратики
Причем именно в таком порядке. У вас даже комментариев к картинке нет на эту тему.
Далее неясен принцип «расслоения» системы. Вы лихо пообъединяли в «слои» некоторые квадратики, что резонно вызывает два вопроса: кому это нужно? что это дает?
Я еще давно писал на эту тему gandjustas.blogspot.ru/2010/11/layered-architecture.html, но до сих пор не все могут разобраться что к чему.
Ну и самое главное.
Архитектура получилась настолько абстрактной, что указание предметной области выглядит притянутым за уши. Вы можете просто в квадратиках написать «Сервис 1», «Сервис 2 итд, не изменится ровным счетом ничего. Это наводит на мысль о том, что данная архитектура претендует на универсальность, а следовательно она бесполезна.
Любой архитектор, глядя на любую схему, должен найти конкретный (инвариантный, понимаемый всеми одинаково) ответ на два вопроса:
1) Что означают стрелочки
2) Что означают квадратики
Причем именно в таком порядке. У вас даже комментариев к картинке нет на эту тему.
Далее неясен принцип «расслоения» системы. Вы лихо пообъединяли в «слои» некоторые квадратики, что резонно вызывает два вопроса: кому это нужно? что это дает?
Я еще давно писал на эту тему gandjustas.blogspot.ru/2010/11/layered-architecture.html, но до сих пор не все могут разобраться что к чему.
Ну и самое главное.
Архитектура получилась настолько абстрактной, что указание предметной области выглядит притянутым за уши. Вы можете просто в квадратиках написать «Сервис 1», «Сервис 2 итд, не изменится ровным счетом ничего. Это наводит на мысль о том, что данная архитектура претендует на универсальность, а следовательно она бесполезна.
ИМХО, схема интересна только для демонстрации заказчику (и то может начнать задавать странные вопросы), слишком много непонятного для реализации.
1) Справочная информация — почему она вдруг оказалаось сквозной по всему проекту? Справочная информация сама по себе появляется везде от базы данных до мобильного клиента? Для неё не нужен API? Что тогда делает пункт «Загрузка НСИ» (ладно оставим в стороне вопрос что вообще такое НСИ, что нигде не указано)?
2) Тоже самое с конфигурацией, чем API администирования занимается если конфигурация отдельна от всего? Или это конфигурация исходного кода? Но зачем тогда она вообще на схеме?
3) Новости — какое API за них отвечает? Вот совсем не вижу подходящего для новостей API. Засунуть в API организации учебного процесса неправильно, а явно на клиентах необходимо показывать новости, или новости вдруг идут не через api или схема явно не полна.
4) «Экспорт и импорт данных» / «обмен данными» / «загрузка данных» это вообще-то синонимы, тут хотя бы стоит указать что один в файл, другой во внешнею систему.
5) Пункты бизнес логики названы так что не понятно к какому API и системе они относятся и что конкретно означают. Например: Отчетность она перед директором, родителями или мин.образования? Обмен сообщениями между кем и кем: родителями и учителем, учителем и директором или директором и мин.образования? Чем например Учебный процесс отличается от Успеваемости + Учебные планы + Домашнее задание? Как используются нормативные документы и методические пособия, это чисто справочники или их формируют учителя/стороние клиенты? На мой взгляд, в бизнес логике надо называть так чтобы было явно понятно что это и зачем, хотя бы так «Модуль журнала посещаемости и успеваемости учеников», «Модуль формирования отчетов для мин.образования», «Модуль формирования отчетов для руководства школы», «Модуль обмена сообщениями учителей с родителями», «Модуль планирования учебного расписания» и т.п.
В целом, увы, это не статья по планированию архитектуры, а как быстро набросить красивую картинку для начальства и заказчика, но которую нельзя толком использовать разработчикам. ИМХО.
1) Справочная информация — почему она вдруг оказалаось сквозной по всему проекту? Справочная информация сама по себе появляется везде от базы данных до мобильного клиента? Для неё не нужен API? Что тогда делает пункт «Загрузка НСИ» (ладно оставим в стороне вопрос что вообще такое НСИ, что нигде не указано)?
2) Тоже самое с конфигурацией, чем API администирования занимается если конфигурация отдельна от всего? Или это конфигурация исходного кода? Но зачем тогда она вообще на схеме?
3) Новости — какое API за них отвечает? Вот совсем не вижу подходящего для новостей API. Засунуть в API организации учебного процесса неправильно, а явно на клиентах необходимо показывать новости, или новости вдруг идут не через api или схема явно не полна.
4) «Экспорт и импорт данных» / «обмен данными» / «загрузка данных» это вообще-то синонимы, тут хотя бы стоит указать что один в файл, другой во внешнею систему.
5) Пункты бизнес логики названы так что не понятно к какому API и системе они относятся и что конкретно означают. Например: Отчетность она перед директором, родителями или мин.образования? Обмен сообщениями между кем и кем: родителями и учителем, учителем и директором или директором и мин.образования? Чем например Учебный процесс отличается от Успеваемости + Учебные планы + Домашнее задание? Как используются нормативные документы и методические пособия, это чисто справочники или их формируют учителя/стороние клиенты? На мой взгляд, в бизнес логике надо называть так чтобы было явно понятно что это и зачем, хотя бы так «Модуль журнала посещаемости и успеваемости учеников», «Модуль формирования отчетов для мин.образования», «Модуль формирования отчетов для руководства школы», «Модуль обмена сообщениями учителей с родителями», «Модуль планирования учебного расписания» и т.п.
В целом, увы, это не статья по планированию архитектуры, а как быстро набросить красивую картинку для начальства и заказчика, но которую нельзя толком использовать разработчикам. ИМХО.
Кстати, первый же вопрос будет — что за нотация использована в модели?
Вроде как UML, но тогда почему сервисы квадратиками? Стрелок таких тоже там не припомню — это потоки данных, интерфейсы или что?
Вроде как UML, но тогда почему сервисы квадратиками? Стрелок таких тоже там не припомню — это потоки данных, интерфейсы или что?
Sign up to leave a comment.
Архитектура приложения малой кровью