Предположим, что с будущей функциональностью Вы определились. Тогда Вы точно знаете, кто или что будет поставлять данные, кто/что будет их потреблять и какие преобразования данных должна выполнять сама система.
Возьмите лист бумаги и карандаш. Если не сильно уверены в своих силах, то ещё и резинку, чтобы править схему. Более продвинутые читатели могут обратиться к профессиональным инструментам для проектирования архитектуры в электронном виде.
Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), — снизу.
Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API — это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем представления. Объедините все прямоугольники с API и обзовите слоем сервисов.
Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.
Между слоем сервисов и слоем доступа к данным нарисуйте большой контур и назовите его слоем бизнес-логики. В маленьких прямоугольниках внутри этого контура перечислите основные бизнес-задачи. Один компонент Вашей системы будет решать одну бизнес-задачу.
Теперь справа нарисуйте несколько длинных прямоугольников снизу доверху и напишите в них: журналирование, конфигурация, мониторинг производительности, обработка исключений и что-то ещё, что является общей инфраструктурой (или сквозной функциональностью) для всех слоёв вашей программы.
Вы получили логическую архитектуру приложения. Разбросайте слои по серверам — получите физическую архитектуру.
Теперь вам остаётся детально проработать каждый маленький квадратик.
Маленький практический пример запрячу под кат.
Для примера я возьму совершенно виртуальный проект системы контроля успеваемости для средней школы. Возьму её по двум причинам. Во-первых, все мы учились в школе. Во-вторых, у многих из нас дети сейчас учатся в той же школе. Из-за этого, надеюсь, предметная область будет всем понятна.
Итак, наша система будет предназначена для ведения электронных дневников учащихся и электронных классных журналов. В довесок пусть система имеет некоторый дополнительный набор функций, позволяющий учащимся, родителям и преподавателям обмениваться сообщениями, а руководству школы — контролировать учебный процесс.
Итак, пользователями нашей системы будут учащиеся, их родители, учителя и руководство школы. Кроме того, пользователями будут являться администраторы системы, которым важно получать информацию о событиях в системе и выполнять некоторые сервисные операции. Перечислять варианты использования не будем, не о них речь.
Пользователи будут взаимодействовать с нашей системой либо посредством web-интерфейса, либо с помощью мобильного приложения. Оба пользовательских интерфейса предназначены для школ, которые не могут себе позволить разработку своего собственного сайта. Остальные смогут обращаться к нашей системе через web-сервисы.
Сервисов будет четыре: электронный дневник, электронный журнал, организация учебного процесса и администрирование.
Под слоем сервисов будет слой бизнес-логики, состоящий из десятка компонентов, решающих бизнес-задачи пользователей.
Данные будут храниться в базе данных. Причём базы будет две: боевая и архивная.
Система будет экспортировать/импортировать данные из файлов. Кроме того, будет две внешние системы, к которым наша система будет подключаться удалённо: система справочной информации и информационная система Департамента образования.
Сквозную функциональность будут составлять механизмы журналирования, мониторинга, управления конфигурацией, обеспечения безопасности.
В итоге, получаем вот такую простую схему:
Теперь можно выделить физические узлы. Web-интерфейс пользователя и сервисы будут развёрнуты в web-кластере. Слои бизнес-логики и доступа к данным будут реализованы на сервере приложений. Базы данных разместятся в отдельном отказоустойчивом кластере. Позже можно будет все узлы изобразить в виде красивой схемы физической архитектуры.
Надеюсь, пример понятен.
Для того, чтобы более глубоко погрузиться в тему, предлагаю обратить внимание на «Руководство Microsoft по проектированию архитектуры приложений». Руководство написано в форме справочника, так что можно быстро найти рекомендации по проектированию каждого слоя системы.
Комментарии (89)
hudson
11.05.2015 21:20+5Кстати, книга находится в свободном доступе на сайте Microsoft: «Руководство Microsoft по проектированию архитектуры приложений»
lair
12.05.2015 00:13+6Выясните [...] к чему будет обращаться Ваша программа. [...] Те, к которым будет обращаться программа (включая БД), — снизу.
У кого выяснять, к чему будет обращаться программа? Если вдруг БД — то какая?
Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.
А если мы обращаемся не к данным, а ко внешним сервисам — все равно слой доступа к данным?
Иногда UI тоже может обращаться к API.
И как решить, у нас это «иногда», или другое «иногда»?
В маленьких прямоугольниках внутри этого контура перечислите основные бизнес-задачи. Один компонент Вашей системы будет решать одну бизнес-задачу.
Вообще-то, декомпоновка предметной области на задачи, и их последующее размещение по компонентам — это задача, требующая немалого опыта. Откуда в вашем случае берется список бизнес-задач? Почему вы считаете, что они соотносятся с компонентами 1-к-1?
Ну да, а еще вы совершенно не учитываете, что секционирование может быть не только по слоям, но и по областям (а у вас, скажем, один слой БД на всю бизнес-логику), что бывает SOA и микросервисная архитектура, ну и так далее.
Но самое-то грустное не в этом. Самое грустное в том, что из вашей схемы совершенно не понятно, что именно в реальности надо делать. Она бессмысленна — в том смысле, что не несет никакого дополнительного понимания, как и сотни подобных схем, кочующих по современным (точнее, слегка устаревшим) пафосным ТЗ.
Вот казалось бы, простой вопрос: почему UI и «сервисный слой» — на веб-кластере (причем одном на всех), а бизнес-логика и слой доступа данных — на «сервере приложений». Там масштабирование не нужно, что ли? А как организовано общение между сервисным слоем и сервером приложений? А как именно организован мониторинг?
FiresShadow
12.05.2015 07:02-2Но самое-то грустное не в этом. Самое грустное в том, что из вашей схемы совершенно не понятно, что именно в реальности надо делать. Она бессмысленна
Пожалуй, комментарии в духе «статья плохая, потому что после прочтения у меня остались вопросы или я что-то не понял» являются очень распространенными на хабре. Если есть вопросы, то можно загуглить, скачать книгу, спросить у автора. Но зачем критиковать? Чтобы полностью осветить все вопросы по проектированию, нужна не одна книга. А это просто статья. И она вполне могла бы быть первой главой в какой-нибудь книге. Она задаёт общее направление для рассуждений, упорядочивает мысли и заинтересовывает читателя в процессе проектирования. Разве этого мало?
sllh
12.05.2015 09:30+4Мало, как правильно указали выше, результатом статьи стало что-то, что назвали «красивой схемой архитектуры». По факту это просто орнаменты по мотивам визио, которые красиво смотрятся в презентации заказчикам из не-IT сферы, но не тянут на громкий заголовок.
lair
12.05.2015 10:16+4Но зачем критиковать?
Чтобы стало лучше, очевидно.
Если есть вопросы, то можно загуглить, скачать книгу, спросить у автора.
Понимаете, это у меня есть эти вопросы, потому что я и так имею представление о процессе проектирования. А откуда они возьмутся у человека, который в ней ничего не понимает? Ну и да, если загуглить и скачать книгу, то можно и вообще без этой статьи обойтись.
Она задаёт общее направление для рассуждений, упорядочивает мысли
А правильное ли это направление? Я вот совершенно не уверен: в статье пропущено достаточно моментов, которые обязательно должны быть оговорены даже в «первой главе».
заинтересовывает читателя в процессе проектирования.
А зачем? Обычно к книгам по архитектуре приходят люди, которые и так знают, зачем им это надо. А тех, кто не знает. может, лучше и не заинтересовывать?
Собственно, вопрос «зачем» — он, как всегда, ключевой. Для чего предназначена схема, разработанная в статье (поверьте мне, ответ на этот вопрос далеко не однозначен)? Для кого и для чего предназначена сама статья?
max-kuznetsov Автор
12.05.2015 11:18-3А зачем? Обычно к книгам по архитектуре приходят люди, которые и так знают, зачем им это надо. А тех, кто не знает. может, лучше и не заинтересовывать?
Не совсем так. Жизнь сложнее. Вот простой пример, когда спроектировать систему нужно (например, руководство отдало приказ программисту), а знаний не достаточно. На то, чтобы читать книги и аккуратно всё применять на практике, времени в этом случае нет. И что парню в этом случае делать? Ему архитектура, может, и не интересна, но работу надо делать. А Вы, вместо того, чтобы ему помочь, предлагаете ему пойти подальше. Нехорошо. Я предложил свой путь решения: быстро набросать схему и воспользоваться Руководством MS, написанным в виде справочника (т.е. не обязательно его читать с самого начала). Методологически моё решение закончено.
Если у Вас есть своё решение, предложите его.lair
12.05.2015 11:24+6Вот простой пример, когда спроектировать систему нужно (например, руководство отдало приказ программисту), а знаний не достаточно. На то, чтобы читать книги и аккуратно всё применять на практике, времени в этом случае нет.
Эээ… отдавать проектировать систему человеку, у которого для этого недостаточно знаний? И нет времени на самообучение?
А Вы, вместо того, чтобы ему помочь, предлагаете ему пойти подальше.
Я предлагаю ему пойти поучиться.
Если у Вас есть своё решение, предложите его.
Я стараюсь не решать flawed problems. Если вы ставите задачу человеку, у которого недостаточно квалификации, ему нужно пойти поучиться. Если у него нет и этой возможности, ему не надо решать эту задачу.
Следуя вашей методологии он, скорее всего, совершит нездоровое количество ошибок, которые впоследствии отразятся на всем проекте.max-kuznetsov Автор
12.05.2015 11:47-2Отдавать проектировать систему человеку, у которого для этого недостаточно знаний? И нет времени на самообучение?
lair, если подходить к вопросу академически, Вы правы. Но реальность, как всегда, шире и глубже.
Вот пришёл ко мне юный архитектор, вроде как образование профильное и всё такое. Но на практике с разработкой архитектуры он в вузе не сталкивался. Что, снова его послать учить? Не работает. Надо натаскивать на практику в боевых условиях. Мой подход в этом случае работает и помогает человеку быстро войти в работу. Уже через пару часов у него есть первый макет архитектуры, и можно с ним говорить о более глубоких деталях.
А в соседнем отделе начальство… дало программисту (даже не ведущему) проектировать систему. Приходит ко мне, типа «как быть». Что, послать его учиться? Да его уволят, хотя, заметьте, не он виноват. Поэтому я даю ему маленький толчок, как начать работу. И дальше он может работать со справочниками типа того же Руководства MS, и задавать вопросы мне, Вам или кому-то ещё из опытных коллег. Это работает. А когда цейтнот спадёт, тогда уже можно послать парня учиться.lair
12.05.2015 12:50+3Вот пришёл ко мне юный архитектор, вроде как образование профильное и всё такое. Но на практике с разработкой архитектуры он в вузе не сталкивался.
Значит, он не архитектор.
Не работает.
Почему же?
А в соседнем отделе начальство… дало программисту (даже не ведущему) проектировать систему. Приходит ко мне, типа «как быть». Что, послать его учиться? Да его уволят, хотя, заметьте, не он виноват.
Почему уволят-то? Должностные обязанности нарушил? А откуда у него в должностных обязанностях проектирование?
Я не знаю, что вы рассказываете людям, которые приходят к вам, но то, что вы пишете в обсуждаемой статье — это толчок в неправильном направлении. Начинать надо с определения задач, а потом — minimum viable architecture. А вы сразу рисуете монстра. Зачем?
vedenin1980
12.05.2015 15:19+1Она задаёт общее направление для рассуждений, упорядочивает мысли и заинтересовывает читателя в процессе проектирования. Разве этого мало?
Лучше вообще не учить, чем учить в корне неправильно. Проблема в частности интернета в том что зачастую школьник, мельком прочитавший книгу для чайников (написанную тоже невеликим гуру), тут же считает себя экспертом и начинает всех подряд учить, в результате учат непонятно чему непонятно зачем. Другой школьник пересказывает уже его статьи и получается такой испорченный телефон дилетантов.
PerlPower
13.05.2015 06:07Она бессмысленна — в том смысле, что не несет никакого дополнительного понимания, как и сотни подобных схем, кочующих по современным (точнее, слегка устаревшим) пафосным ТЗ.
Есть такая беда.
RPG18
12.05.2015 00:32+1Глядя на конечную схему, сразу вспоминается астронавт архитектуры. Архитектура это компромисс между требованиями и имеющимся ресурсами, т.е. вся эта красивая архитектура может не уложиться в бюджет и сроки.
От tutorial'а для молодых коллег ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.max-kuznetsov Автор
12.05.2015 09:27-7ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система
Если Вам нужно такое подробное руководство, то ссылка на него приведена в конце статьи. Почитайте.lair
12.05.2015 10:17Где-то есть руководство, в котором описаны задачи, которые решает система, которую я проектирую?
max-kuznetsov Автор
12.05.2015 11:50-3Вопрос RPG18 был о руководстве для для молодых архитекторов, а не о руководстве к Вашей собственной системе. Вы невнимательны.
lair
12.05.2015 12:51Разве?
ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.
(выделение мое)max-kuznetsov Автор
12.05.2015 14:02От tutorial'а для молодых коллег ожидал четко сформулированных задач, которые должна решать будущая система, и список требований, которым должна удовлетворять будущая система.
Это полная цитата. Так что вопрос переадресуйте автору комментария.lair
12.05.2015 14:31+1Ну так все правильно: в туториале должно быть четко сформулировано, как и откуда это все берется. У вас этого нет.
RPG18
12.05.2015 16:22+3lair правильно понимает. Нужно определить круг задач, которые будет решать будущая система. А без требований к системе, не понятно, откуда появились:
- две базы;
- мобильное приложение;
- система справочной информации;
- информационная система Департамента образования;
- отказоустойчивый кластер.
Оба пользовательских интерфейса предназначены для школ, которые не могут себе позволить разработку своего собственного сайта.
Не могут позволить сайт, но могут позволить себе отказоустойчивый кластер?
boblenin
13.05.2015 22:10Да уж. Четко сформулированые задачи сделали бы нашу жизнь гораздо проще. Однако мы не в плановой экономике живем, а при каком-то виде более-менее свободного рынка. А рынок — штука изменчивая и выживает тот, кто лучше адаптируется.
Это касается людей, организаций и даже систем.
С одной стороны чем меньше мы делаем допущений — тем меньше тратим впустую ресурсов. Но при недостаке фактических данных (а будущее никто не знает), допущения делать приходится. Остается делать допущения, которые будут верны с большей вероятностью или которые будут стоить меньше ресурсов.
То, что сделал автор статьи — это несколько допущений, которые потратили впустую ресурсы и впридачу еще и наверняка не верны в рамках задачи.
Хороший пример того, как делать не надо.
Valle
12.05.2015 05:58+1Я правильно понял, что на этой схеме написано «это вебсервис онлайн-дневника, где журналирование, конфигурация и безопасность побоку»?
SVVer
12.05.2015 06:05Скорее, это просто сквозная функциональность, которая может требоваться на всех слоях. Она на таких схемах обычно рисуется сбоку.
lubezniy
12.05.2015 08:34Если из архитектуры потом вырастает проект, то это становится тождественным.
SVVer
12.05.2015 09:08Вы не могли бы пояснить, что имеете ввиду?
lubezniy
12.05.2015 10:10То, что безопасность находится именно «сбоку» без явных связей с другими модулями, и никто потом толком не знает, как её пристроить в получившееся огромное приложение, чтобы по возможности охватить как можно больше потенциально проблемных мест. В принципе уже на этапе построения архитектуры не мешало бы прорисовать возможных «врагов» по векторам атаки и частично модули безопасности. Например, в этой схеме к WebUI наряду с пользователем можно дорисовать вредного хакера (сканирование портов на сервере, проба разных эксплоитов, CSRF и т. п), между пользователем и WebUI пристроить MitM, а к WebUI сразу дорисовать модуль аудита безопасности. Это позволит при детальной проработке учесть эти моменты в технических и функциональных требованиях к тем или иным модулям.
SVVer
12.05.2015 10:32+1А нельзя ли при детальной проработке упомянутые Вами моменты и добавить? Не это ли называется детальным проектированием? А представленная схема является лишь описанием высокоуровневой архитектуры. И она явно не единственная, о чем автор, к сожалению, явно не упомянул
Согласен, какие-то моменты относительно безопасности, например, могли бы появиться и на этой схеме. Особенно, если они архитектурно важны. Но если отметить на этой схеме все нюансы безопасности, то остальные элементы системы на этом фоне померкнут. А насколько я понимаю, высокоуровневое описание архитектуры предназначено для того, чтобы согласовать общее «архитектурное видение» системы со всеми участниками проекта, среди которых могут быть специалисты разного профиля.lubezniy
12.05.2015 18:24Лишь в части. На общем уровне проектируется, что делаем, а на детальном — как. Решили в целях безопасности журналить — рисуем журналирование, а на детальном проектировании уже писать, какие данные журналировать, откуда их брать и куда писать. Решили делать резервное копирование — нарисовали модуль; связи (что копируем, куда и как) будем рассматривать на детальном уровне. Решили делать https — рисуем, а на детальном уровне определяемся, где и как реализовывать.
max-kuznetsov Автор
12.05.2015 09:30Нет, не побоку, а сбоку. Сквозная функциональность пронизывает все слои логической архитектуры, поэтому в выбранной нотации их рисуют вертикально, а чтобы схема была читаемой, сдвигают вправо.
Valle
12.05.2015 18:07+1Безопасность — это не совсем функциональность. Если сначала все сделать, а потом посмотреть, что осталась нереализована «безопасность», то наверное, уже довольно поздно что-то делать. Это то, что нужно держать в уме для каждой строки кода. То же с журналированием. Зачем оно сквозное и что оно будет журналировать, куда оно будет журналировать на каждом слое архитектуры? lubezniy правильно сказал, что на практике вся эта функциональность будет не сквозная, а побоку. Если же подразумевается, что это само собой разумеющиеся вещи, то зачем оно на схеме? Так можно и «безглючность», «красивый код», «стабильность» туда поместить имхо.
valis
12.05.2015 09:00Архитектуру нельзя описать руководством. Каждый проект это уникальное явление и каждая команда тоже уникальна. Архитектура гораздо шире технических аспектов, это договоренность между всеми участниками проекта. На паттерны, языки, фреймворки и т.п оказывает влияение не только т.з, но и сроки, бюджет, в конце концов скилы команды.
К чему это я? Ах да, не существует руководств типа «Делать вот так, шаг за шагом», многие книги это сборники советов.sllh
12.05.2015 09:25Кстати, SEI, пожалуй, единственные, кто пытаются стандартизировать подходы в проектировании систем (вернее, пытаются-то не единственные, но единственные, кто преуспели). Достаточно действенен тот же самый Quality Attribute Workshop, который позволяет в сжатые сроки сдоить с холдеров дополнительные критерии.
boblenin
12.05.2015 10:07-3Архитектуру надо придумывать только тогда, когда продукт рефакторится. До этого создавать самое простое, что возможно; обвешивать датчиками (измерять все что можно) и по необходимости оптимизировать узкие места, покрывать все тестами и чистить код и инфраструктуру от пахнущих кусков.
Многократно сталкивался с архитектурой в waterfall стиле. Ни разу не работало так, как нужно бизнесу в первых двух-трех крупных версиях.valis
12.05.2015 10:30-2Архитектуру нужно ДОКУМЕНТИРОВАТЬ тогда, когда в разработке учавствует больше 1-го человека. Если ее пишет один человек, нет проблем — у него в голове и патерны и фреймворки, и структура БД. Документ это прежде всего средство коммуникации.
max-kuznetsov Автор
12.05.2015 10:45Не согласен. Архитектуру надо документировать даже, если в проекте один человек, но продукт предполагает длительное использование и может развиваться в будущем. Человек уйдёт с проекта и забудет о нём. Как восстанавливать причины всех принятых решений, если потребуется через год что-то добавить? Пролезть по всему коду? Это будет значительно дороже, чем сделать сразу нормальное, пусть и не формальное, описание архитектуры.
Valle
12.05.2015 18:10Обычно код описывает все значительно точнее. Если из кода непонятно, что происходит, то и документация наверное мало поможет.
lubezniy
13.05.2015 00:44+2Смотря какой код (вернее, смотря насколько он сложнее Hello World) и какая документация. Скажем, при наличии прорисованной в виде отдельного документа схемы взаимодействия модулей искать местоположение каких-либо багов в существующей большой системе гораздо проще, особенно человеку, который только входит в этот проект.
boblenin
13.05.2015 20:43-1Вы пытаетесь убедить архитектора в том, что то, что он делает — не нужно. Я не думаю, что вам удастся.
lair
13.05.2015 21:33Почему не нужно-то? Вы считаете, что работа архитектора состоит в написании документации?
boblenin
13.05.2015 22:001) Я не считаю работу архитектора не нужной.
2) Я не считаю что работа архитектора — это написание документации (впрочем это одна из вещей которой архитектор занимается в рабочее время, как и многие другие роли в SDLC)
Я считаю что объяснять архитектору то, что его работа не нужна — бессмысленно.
1) Это не так
2) Если даже так (не все архитекторы одинаково полезны), то вы не собеседника-архитектора не убедите
3) Даже если убедите — он не признается, что согласен
4) Если признается, то он уже не архитектор и тогда см п2lair
14.05.2015 00:371) Я не считаю работу архитектора не нужной.
2) Я не считаю что работа архитектора — это написание документации (впрочем это одна из вещей которой архитектор занимается в рабочее время, как и многие другие роли в SDLC)
Тогда я не понимаю, почему вы считаете, что в этой дискуссии кто-то пытается убедить архитектора в том, что то, что он делает — не нужо.
max-kuznetsov Автор
12.05.2015 11:00+3Архитектуру надо придумывать только тогда, когда продукт рефакторится.
Её нужно начинать продумывать уже на стадии формирования концепции продукта. Даже для гибкой методологии это необходимость. При рефакторинге адекватное описание архитектуры поможет быстро найти точки вмешательства.
До этого создавать самое простое, что возможно; обвешивать датчиками (измерять все что можно) и по необходимости оптимизировать узкие места, покрывать все тестами и чистить код и инфраструктуру от пахнущих кусков.
Ранняя разработка архитектуры нужна, прежде всего, чтобы избежать масштабных циклов тестирования — исправления ошибок в конце спринта. Если же архитектуру и детальное проектирование не проводить, то команда заплатит очень дорого за ошибки, которые можно было легко устранить на ранних стадиях, когда неверные решения ещё не были облеплены слоями кода.
Как говорил Макконнелл:
«Тестирование представляет собой способ определения уровня качества программного продукта, а не способ его обеспечения.»
И ещё цитата из Руководства Microsoft, указанного в конце статьи:
«Важно, особенно при проектировании и разработке по гибкому процессу, чтобы итерация включала как проектирование архитектуры, так и разработку реализации. Это поможет избежать масштабного проектирования наперёд.»
boblenin
12.05.2015 15:15+1Можете поподробнее объяснить откуда возьмутся масштабные циклы тестирования в спринте, если в нем делали все согласно KISS & DRY?
Плюс интересует каким образом архитектура, придуманая на стадии концепции (когда не известно ни поведение системы под нагрузкой, ни собтсвенно сам характер нагрузки) поможет чего-то избежать. Не могли бы вы объяснить, Максим?
Заранее спасибо.max-kuznetsov Автор
12.05.2015 15:44boblenin, не надо передёргивать. Я сказал, что архитектуру «нужно начинать продумывать уже на стадии формирования концепции продукта.» Но не сказал, что на стадии концепции работа над архитектурой заканчивается. Основная работа проводится, когда основные функциональные требования становятся известны. Как было указано в приведённой мной выше цитате, «важно, особенно при проектировании и разработке по гибкому процессу, чтобы итерация включала как проектирование архитектуры, так и разработку реализации». И это — на каждой итерации.
Спринт одной системы отличается от спринта другой системы. В том числе и по масштабу. Всё, что выполнено в рамках спринта, должно быть проверено. Если количество нового/изменённого кода было много или/и были затронуты многие компоненты, тестирование может быть весьма серьёзной задачей. Проще и дешевле подумать до того, как отрезать, чем пытаться пришить отрезанное.
И ещё раз, тестирование — это подход к контролю качества, а не способ его обеспечения.
Пожалуйста.
boblenin
12.05.2015 18:35> Я сказал, что архитектуру нужно начинать продумывать уже на стадии формирования концепции продукта.
> Основная работа проводится, когда основные функциональные требования становятся известны.
Ну если так — прошу прощения, за взаимное недопонимание. С такой постановкой вопроса спорить глупо.
> Спринт одной системы отличается от спринта другой системы. В том числе и по масштабу.
Безусловно. И размер комманды (в широком смысле) тоже отличается, остаются пропорции. И сохранение пропорций в какой-то мере позволяет говорить о количестве функционала в системах в рамках спринта используя схожие допущения.
Системы, где архитектура развивается отвечая вызовам реального мира в противовес подходу — сначала все спроектируем, а потом будем 10 спринтов строить согласно начальной архитектуре, гораздо проще и с точки зрения разработки и с точки зрения тестирования.
> И ещё раз, тестирование — это подход к контролю качества, а не способ его обеспечения.
Разумеется. Но при чем здесь архитектура?
sllh
12.05.2015 17:14Эм,
Плюс интересует каким образом архитектура, придуманая на стадии концепции (когда не известно ни поведение системы под нагрузкой, ни собтсвенно сам характер нагрузки) поможет чего-то избежать
Вы, надеюсь, не серьезно? Вообще-то поведение системы под нагрузкой является как раз одним из входных параметров, при проектировании систем, а не «потом сбоку докрутим, чтобы не лагало».boblenin
12.05.2015 18:37-1> Вы, надеюсь, не серьезно? Вообще-то поведение системы под нагрузкой является как раз одним из входных параметров, при
> проектировании систем, а не «потом сбоку докрутим, чтобы не лагало».
Совершенно верно. Для этого даже термин (паттерн) придуман.
Stas911
13.05.2015 05:32+1Этот паттерн совершенно не про архитектуру, а про оптимизацию КОДА.
boblenin
13.05.2015 15:33Я конечно понимаю, что глупо будет попытаться вас переубедить, но вот к примеру википедия с вами не согласна. en.wikipedia.org/wiki/Program_optimization
И да. Если вы считаете что паттерны и антипаттерны — это о том как правильно кодировать, то это вполне себе ваше право.Stas911
13.05.2015 15:47+1Я правильно понимаю, что вы считаете, что можно разработать архитектуру даже не зная примерно ожидаемой на систему нагрузки?
boblenin
13.05.2015 15:55Я разработал достаточно систем, чтобы знать, что ожидаемая нагрузка практически никогда не совпадает с тем, что реально происходит. Систему нужно изучать — для этого надо не гадать, а обвешивать все хуками и софтом для мониторинга, логами и тд. Примерно ожидаемая нагрузка — это гадание. Recipe for disaster.
Те, места которые кажутся потенциально узкими в начале разработки и даже на более поздних этапах далеко не всегда таковыми являются в продакшене.
Мне доводилось работать с приличным количеством систем, где разработчики и архитекторы оптимизировали систему на ранних этапах (кэширование не в правильных местах, параллелизация там где не нужно, да много чего) и все эти «оптимизации» превращались в костыли, которые портили жизнь всем до тех пор пока их не выпиливали.Stas911
13.05.2015 16:59«Примерно ожидаемая нагрузка — это гадание» — ну, если это замена legacy system или автоматизация известного процесса — то все статистика на руках обычно.
boblenin
13.05.2015 20:42Ну так я с этого и начал. «Архитектуру надо придумывать только тогда, когда продукт рефакторится.». Когда мы строим тот же самый продукт второй, третий и тд. раз — то ясно, что много чего о нем уже знаем и можем сразу сделать лучше.
lubezniy
12.05.2015 18:38А когда нагрузка заранее не известна (есть идея, по которой ещё не понятно, «выстрелит» она или нет, или «выстрелит» частично)? Бывает на старте: создаётся новый проект, по которому ещё нет данных по предполагаемому спросу (рынок не сформирован), и после реализации проекта предстоит провести определённую работу по раскрутке бизнеса с неизвестным результатом. Чем больше наплодишь в архитектуре (масштабирование, резервирование, etc), тем больше заказчик потеряет денег и времени в случае неудачи. С другой стороны, какой-нибудь программист Вася за копейки склепает прототип на старт, что помещается на одном сервере или даже виртуалке; а тут проект «выстреливает», и начинаются траблы с прототипом, т. к. архитектура толком не продумана и не документирована.
sllh
13.05.2015 05:27Я не говорю, что стоить сразу писать приложение с учетом нагрузки как у гугла или фейсбука и пихать везде мезос, но в современном мире существует достаточно много паттернов проектирования, сводящих необходимость переписывания или овер-инжениринга к минимуму. Те же SOA/Microservices не требуют дополнительных усилий, но позволяют заранее застраховаться от многих проблем в будущем.
На тему прототипа, прототип — это прототип. Никто в здравом уме не будет допиливать продукт, который склепал Вася, а оставят его как паблик альфу и сбоку с нуля построят нормальное решение. Но прототип, MVP, PoC или как хотите его назовите — это не более, чем оценка интереса таргет аудитории, а никак не «болванка» для системы, которая пойдет в продакшн. ОК, возможно какой-нибудь сайт на вордпресе и можно дотянуть из прототипа, но в контексте статьи мы говорим о системах с более высокой сложностью.boblenin
13.05.2015 15:35Кстати вот SOA/Microservices — создают достаточно приличные накладные рассходы (на разработку, инфраструктуру, тестирование и тд), особенно когда их лепят не к месту.
lair
13.05.2015 15:46+2Никто в здравом уме не будет допиливать продукт, который склепал Вася, а оставят его как паблик альфу и сбоку с нуля построят нормальное решение.
К сожалению, «в жизни» это не обязательно так. За последние два года я видел три прототипа, которые потребовали запустить в проде.boblenin
13.05.2015 16:06И так бывает. И на мой взгляд это не худший вариант. На прототипе можно жить некоторое время, изучая пользователей, подпирая костылями то что падает — покупая время для следующей версии.
Гораздо хуже, когда на этапе прототипирования сделали супер-пупер комбайн, который с помощью конфигурационного файла превращается из CMS в распределенную peer-to-peer базу данных, но при этом бизнесс не взлетел и все нужно выбрасывать.
SemenovVV
12.05.2015 11:19+5проект системы контроля успеваемости для средней школы. Возьму её по двум причинам. Во-первых, все мы учились в школе. Во-вторых, у многих из нас дети сейчас учатся в той же школе. Из-за этого, надеюсь, предметная область будет всем понятна.
Понятно будет со стороны родителя и то не всякого.
а со стороны учителя, завуча — директора, роно и т.д. предметная область вам понятна?
Предметная область с их точки зрения возможно видится по другому.
Вы предлагаете проектировать архитектуру не имея сформулированных требований к системе. Как следствие вы сразу предлагаете трех звенку и не рассматриваете альтернативы.
С моей точки зрения, для системы контроля успеваемости всю бизнес логику можно засунуть в БД на уровень хранимых процедур.
Боюсь что когда архитектура создается малой кровью, большая кровь появляется на этапе реализации и сопровождения.max-kuznetsov Автор
12.05.2015 12:02-1Цель статьи — не разработка электронного дневника. Её цель — показать, с чего и как можно начать проектировать систему. Соответственно, пример, приведённый в статье, — всего лишь иллюстрация. Если бы я начал погружаться в детали, потерялась бы основная идея.
Если вас волнует вопрос о концепции самого дневника, предметной областью я владею с разных сторон. Бизнес-логику в БД в данном случае засунуть не удастся.
когда архитектура создается малой кровью, большая кровь появляется на этапе реализации и сопровождения.
Если подходить академически к вопросу, то согласен полностью. Но если со стороны реальности, то получается «как всегда», увы. И эта ситуация не всегда зависит от нас. Хотя да, архитектору надо стремиться к самосовершенствованию и быстро переходить из стадии выживания в стадию стабильного развития.SemenovVV
12.05.2015 12:10Бизнес-логику в БД в данном случае засунуть не удастся.
Почему я должен в данном вопросе верить вам на слово? хотя вы возможно и правы, я предметной областью не владею. Нужны очень серьезные доводы, которых без сформулированных требований к системе не может быть.MiKXMan
12.05.2015 12:36-2А в чем смысл засовывать бизнес-логику в БД? Какие в этом плюсы?
Сам смысл базы данных в том, что она должна хранить данные, а не реализовывать бизнес логику.SemenovVV
12.05.2015 12:52+1Все зависит от задачи, есть ИС ( сложнее школьного дневника ), в которых бизнес логика реализована на уровне хранимых процедур и триггеров.
Зачем тогда существуют хранимые процедуры?
gandjustas
12.05.2015 14:35-1Хранимые процедуры позволяют логику обработки данных держать вместе с данными. Это очень актуально для DWH (OLAP) сценариев. Для OLTP, когда правила обработки транзакций меняются чаще, чем данные, использовать хранимки скорее невыгодно.
MiKXMan
13.05.2015 02:27Ну, как минимум, это наследие двух-звенной клиент-серверной архитектуры, когда кроме как в хранимках, серверную бизнес-логику разместить было негде.
В случае с трех-звенкой какой смысл использовать хранимые процедуры, а не реализовывать бизнес-логику на сервере приложений?sllh
13.05.2015 05:35Активное использование хранимок достаточно распространено при построении систем на базе CQRS подхода, но даже там не идет полный перенос БЛ на базу. Это, скорее, наследние старых времен.
boblenin
13.05.2015 22:19Не могли бы вы пояснить каким образом CQRS хоть как-то связан с хранимыми процедурами?
boblenin
13.05.2015 22:17Один из полезных сценариев применения хранимых процедур — это уменьшение нагрузки на канал связи с БД.
Другой — это сокрытие реализации, хотя в этом случае лучше другие способы.
Stas911
13.05.2015 05:35Проектировать систему обычно начинают с разработки BRD и FSD, на основании которых уже и создается архитектура
gandjustas
12.05.2015 13:19+7Статья ни о чем. Я верю, что вы прочитали руководство MS по рисованию квадратиков, но ваша попытка передать «краткое содержание» не удалась.
Любой архитектор, глядя на любую схему, должен найти конкретный (инвариантный, понимаемый всеми одинаково) ответ на два вопроса:
1) Что означают стрелочки
2) Что означают квадратики
Причем именно в таком порядке. У вас даже комментариев к картинке нет на эту тему.
Далее неясен принцип «расслоения» системы. Вы лихо пообъединяли в «слои» некоторые квадратики, что резонно вызывает два вопроса: кому это нужно? что это дает?
Я еще давно писал на эту тему gandjustas.blogspot.ru/2010/11/layered-architecture.html, но до сих пор не все могут разобраться что к чему.
Ну и самое главное.
Архитектура получилась настолько абстрактной, что указание предметной области выглядит притянутым за уши. Вы можете просто в квадратиках написать «Сервис 1», «Сервис 2 итд, не изменится ровным счетом ничего. Это наводит на мысль о том, что данная архитектура претендует на универсальность, а следовательно она бесполезна.boblenin
13.05.2015 22:20> Это наводит на мысль о том, что данная архитектура претендует на универсальность, а следовательно она бесполезна.
Золотые слова!
vedenin1980
12.05.2015 14:08+2ИМХО, схема интересна только для демонстрации заказчику (и то может начнать задавать странные вопросы), слишком много непонятного для реализации.
1) Справочная информация — почему она вдруг оказалаось сквозной по всему проекту? Справочная информация сама по себе появляется везде от базы данных до мобильного клиента? Для неё не нужен API? Что тогда делает пункт «Загрузка НСИ» (ладно оставим в стороне вопрос что вообще такое НСИ, что нигде не указано)?
2) Тоже самое с конфигурацией, чем API администирования занимается если конфигурация отдельна от всего? Или это конфигурация исходного кода? Но зачем тогда она вообще на схеме?
3) Новости — какое API за них отвечает? Вот совсем не вижу подходящего для новостей API. Засунуть в API организации учебного процесса неправильно, а явно на клиентах необходимо показывать новости, или новости вдруг идут не через api или схема явно не полна.
4) «Экспорт и импорт данных» / «обмен данными» / «загрузка данных» это вообще-то синонимы, тут хотя бы стоит указать что один в файл, другой во внешнею систему.
5) Пункты бизнес логики названы так что не понятно к какому API и системе они относятся и что конкретно означают. Например: Отчетность она перед директором, родителями или мин.образования? Обмен сообщениями между кем и кем: родителями и учителем, учителем и директором или директором и мин.образования? Чем например Учебный процесс отличается от Успеваемости + Учебные планы + Домашнее задание? Как используются нормативные документы и методические пособия, это чисто справочники или их формируют учителя/стороние клиенты? На мой взгляд, в бизнес логике надо называть так чтобы было явно понятно что это и зачем, хотя бы так «Модуль журнала посещаемости и успеваемости учеников», «Модуль формирования отчетов для мин.образования», «Модуль формирования отчетов для руководства школы», «Модуль обмена сообщениями учителей с родителями», «Модуль планирования учебного расписания» и т.п.
В целом, увы, это не статья по планированию архитектуры, а как быстро набросить красивую картинку для начальства и заказчика, но которую нельзя толком использовать разработчикам. ИМХО.
Stas911
13.05.2015 05:45+1Кстати, первый же вопрос будет — что за нотация использована в модели?
Вроде как UML, но тогда почему сервисы квадратиками? Стрелок таких тоже там не припомню — это потоки данных, интерфейсы или что?
grossws
Разработка трехвенки в этом посте очень напоминает руководство по рисованию совы
max-kuznetsov Автор
Рад, что вам понравилось.
К сожалению, есть молодые коллеги, для которых уже вопрос о том, с чего начать проектирование системы, вызывает дрожь. А когда речь идёт об очень сложных системах, оторопь берёт и опытных архитекторов. Хотя суть-то остаётся почти той же, разве что решение бывает несколько хитрее и, вы правы, содержит гораздо больше подсистем, слоёв и уровней.
hudson
grossws вероятно имел в виду туториал по рисованию совы в стиле «нарисуйте 2 овала, дорисуйте остальную сову» (пример). Скорее всего он намекает, что «как рисовать остальную сову» тем самым новичкам совершенно непонятно. Архитектуру нельзя объяснить на пальцах, нужна более подробная статья. Вероятно даже цикл статей с поэтапным «рисованием совы».
max-kuznetsov Автор
Не согласен. Поэтапное рисование
совыархитектуры можно найти, в том числе в Руководстве Microsoft, предлагаемом в конце статьи.Но есть нюанс: в руководствах пропущен самый первый шаг. Остаётся открытым вопрос, как же начать проектировать систему. Я даю простой приём, который применим для любой системы и в любой нотации: начать от внешних систем и пользователей и постепенно углубляться внутрь.
Нотацию для своего примера я выбрал ту, которая, по моему опыту, наиболее понятна новичкам. Но тот же подход можно применить, рисуя схему в EnterpriseArchitect с использованием Archimate. Только объяснять условные обозначения придётся долго.
Так что с точки зрения методологии тут всё в порядке. Не надо отбрасывать последний абзац.
eugenius_nsk
FiresShadow
Интересно, а паттерн MVC по-вашему имеет отношение к разработке архитектуры?
eugenius_nsk
Разумеется имеет (равно как и трёхзвенная архитектура). Но это не единственное возможное решение. И разработка архитектуры как раз и заключается в том, чтобы из всего спектра возможных решение выбрать наиболее подходящее в конкретном случае. И именно об этом в данной статье ничего и не сказано — а сказано только, как нарисовать красивую картинку для одного из вариантов решений.
HotIceCream
Судя по последнему абзацу так и было задумано.
eugenius_nsk
При этом даже выбор именно трёхзвенки желательно обосновать. Да, это очень частое решение, но всё же не всегда самое лучшее — а иногда и откровенно вредное.