Использование архитектурных паттернов на практике

Данный пост пишется в контексте курса “Системная инженерия”.

Об архитектурных паттернах как о политике можно говорить долго и всегда что то да останется “за скобками”.

В моей практике использовались/используются в той или иной мере паттерны mvc, microservice, pub-sub, eda (event driven architecture). Нужно заметить что лично в моей практике практически не было проекта где был бы использован только один паттерн, всегда получается какой то микс из пары каких либо паттернов. И причиной этому конечно же неиспользование системного подхода при проектировании системы, впрочем эта компонента (сделай сейчас проектировать будешь потом) встречается к сожалению часто в сфере IT.
Но, веря в лучшее, буду верить и в том что когда нибудь я найдусь с хорошим проектом на котором помимо всех обычных положенных положительных моментов будет и практика системного подхода включая проработку архитектуры до а не после MVP.

Не хочется вас разочаровывать. Но вероятность существования такого проекта крайне мала. Архитектура прорабатывается/изменяется не до или после, а постоянно. Как и код проекта. Как и решения принимаются постоянно, хотим мы того или нет. Я думаю, что системный подход позволит повысить качество принятия решений, в том числе архитектурных.

3 лайка

Как раз с точки зрения системной инженерии и “всего немпрерывного” не думаю, что это праивльное сочетание - серьезная проработка архитектуры заранее и потом создание MVP.
Цель MVP - снять неопределенности в понимании окружения целевой системы и соответстенно требуемых функций целевой системы. Поэтому в тех случаях, когда такая неопределенность высокая, прорабатывать архитектуру нельзя, заранее это лишняя трата ресурсов и времени.
Другое дело, что после MVP, а может и после нескольких стадий, нужно иметь в себе силы выкинуть первоначальную архитектуру и сделать новую. Вернее даже не выкинуть, а постепенно модернизировать, опять же непрерывность и итеративность.

Но даже в областях, где вроде всё вроде бы понятно заранее, есть и изменение понимания целевой системы (архитектором/разработчиком) и изменение потребностей окружения. Так что практически нет проектов, где получается сесть сделать сразу хорошо.

Конечно, какая речь может идти о “серьёзной” проработке архитектуры до MVP. Но, можно собрать максимум данных для создания представления об ожидаемом функционале целевой системы, и исходя из этого подготовить базовую архитектуру которая в дальнейшем будет относительно легко расширяться. Вместо зачастую применяемого подхода “есть задача1 → решаем → есть задача2 + выяснились дополнительные нюансы → полностью переделываем то что было по задаче1 потому что не учли какие то моменты”.

мне кажется(поправьте если не прав), что тут использование микса из паттернов рассматривается как негатив.
Если рассматривается как негатив - то я с этим не согласен. Я вполне допускаю микс паттернов для разных частей системы

А вы проходите сейчас системную инженерию? Книжки по архитектуре прочитали уже?

Насколько я понимаю, у нас много вопросов к целям бизнеса. Т.е. конечно лучше подумать, чем не подумать. Но вот эти соотношения насколько подробно подумать и о чём именно, оно варьируются же. Из роли архитектора да, можно бы собрать “-ости”, которые мы хотим для архитектуры. Потом посмотреть и понять, что выполнить их все одновременно не получится. Проставить приоритеты. И оставить минимальный набор самого важного. И снова мы возвращаемся к тому что на разных этапах, разные характеристики архитектуры для разного бизнеса будут иметь разную важность. И всё равно полностью переделываем вполне нормальная история. Ситуация изменилась - переделываем. Не можем не переделывать.

Как негатив рассматривается хаотическое/спонтанное смешивание паттернов в пределах одного сервиса при микросервисной архитектуре, в таком случае высокая вероятность того что функциональные роли для сервисов…нужно пересмотреть.
Когда случается кейс смешанных паттернов в результате взвешенного/продуманного стратегически подхода (интересно бы всё таки ознакомиться с подобными примерами) то конечно такое может только приветствоваться.

1 лайк

Да, прохожу системную инженерию. Книжки…к сожалению (а может и не к сожалению :)) по тематике не читаю потому что время загружено другими (тоже нужными) делами/чтениями, вот даже художественную почти не читаю хотя раньше достаточно много её поглощал, информация из тематической литературы не планируется применяться “прямо сейчас” а без применения соотвественно и быстро заложится чем то ещё…

“вопросов к целям бизнеса”…возможно скорее к “методам достижения целей”, ведь основная цель бизнеса обычно очевидна…