Comments 25
Интересно, легко, понятно. Хорошие сравнения. С дебютом!
История видала подобные классификации
Животные делятся на:
принадлежащих Императору;
набальзамированных;
прирученных;
молочных поросят;
сирен;
сказочных;
бродячих собак;
включённых в эту классификацию;
бегающих как сумасшедшие;
бесчисленных;
нарисованных тончайшей кистью из верблюжьей шерсти;
прочих;
только что разбивших цветочную вазу;
похожих издали на мух.
Благодарю за такую интересную параллель! Может быть, моя статья действительно немного напоминает подобные классификации своим желанием упростить сложное. Но моя цель — не запутать, а наоборот, сделать архитектуры ПО понятными и даже немного увлекательными. Если получилось, то это уже успех! Я начинаю с самого начала, с того, с чего все мы когда-то начинали, чтобы помочь тем, кто только делает первые шаги в этой теме.
Это хорошее начинание.
Предыдущий комментатор справедливо обратил внимание, что статье не хватило четкого основания для классификации.
Я бы еще обратил внимание на "жизненные примеры". Где-то они есть, где-то их нет. Во всяком случае, лично я под жизненными примерами ожидаю, что будут бытовые вещи, как в случае с чистой архитектурой. Или где резюмируете, что архитектура - как рецепт. Это даже было бы идеально вынести в начало статьи.
Для монолита, микросервиса, микрофронтенда, MVC, EDA (допустим, мы принимаем данную классификацию) таких примеров не встретилось. Если вам удастся их подобрать - будет очень круто.
Знание модных названий - зачет.
А теперь попробуем перейти к практическим вопросам.
Вот вам репозиторий для примера:
https://github.com/LibreOffice/core
Что вы можете сказать об архитектуре этого проекта?
Ваш комментарий, возможно, показался немного снисходительным, как будто сказан с высоты опыта и насмешкой, но его можно было бы подать интереснее и полезнее, и я вижу в нём хороший потенциал для конструктивного обсуждения. Например, вы могли бы отметить, как в LibreOffice применены описанные в статье подходы. 😉
Ну или вы хотели лёгкую подачу от меня про LibreOffice? :)
Тогда вот она: представьте огромный офис, где у каждого отдела (Writer, Calc, Impress) свои задачи. Эти отделы общаются через общего курьера (SAL), а вся инфраструктура, от интернета до кофемашины (VCL), поддерживает их работу. Каждый слой делает своё дело, чтобы офис работал как единая система. Конечно, иногда курьер может застрять в лифте или кофе закончится в самый неподходящий момент, но в этом и есть сложность архитектуры!
Зпбыли еще об одном типе: "Свалка". В нем сочетаются несколько типов архитектур. По моим наблюдениям - самый распространенный. Особенно часто попадается его разновидность "Распределенный монолит"
Serverless выглядит тут неуместно немного, так как затрагивает скорее способ доставки сервисов.
Иногда попытка упростить делает все только запутаннее. Новички которые погружаются в этот дивный мир it вместо того что бы включить голову и, как вы, разобраться - берут за основу аналогичные статьи с упрощением и потом на собеседованиях очень удивляются отказам…
Не всегда стоит упрощать)
Насколько корректно эти 7 типов противопоставлять друг другу? Разве Event-Driven-архитектура - не может быть реализована на микросервисах? Или MVC - разве не может быть реализована в монолите или тех-же микросервисах?
Та же самая мысль возникла. Классификация некорректна, так как смешивает в кучу всё подряд. Например: "Кофе бывает горячий, а бывает с молоком". Вот только чаще всего кофе одновременно и горячий, и с молоком.
Автор молодец, что хотя бы попыталась разобраться, но перед публикацией статьи всё-таки стоит разобраться поглубже.
Вот Бушманн озаботился вопросом, с 1996 серию книжек написал https://en.wikipedia.org/wiki/Pattern-Oriented_Software_Architecture Его цитируют, но по мне больше похоже на коллекцию чем классификацию. Автор, может у вас лучше получится.
Хорошая статья, спасибо автору!
Но а как же Viper, MVVM, MVP?
И более общий вопрос - что такое архитектура приложения?
Плюс один к вопросу )
Было бы хорошо начать с простого и понятного определения архитектуры и зачем она нужна , тогда и примеры и описания возможно бы выстроились в понятную логику и появились основания не путать паттерны проектирования MVC Rvent Driven … и фреймворки ))
Это уже ближе к софтваре архитектуре. По факту это самый низкий уровень. Гораздо интереснее смотреть на то, что на уровень выше. На хабре была обзорная статья на эту тему, вот интересно было бы почитать про паттерны на более высоких уровнях.
Интересная статья, спасибо.
Я бы ещё для наглядности, иллюстрации добавил к каждой архитектуре)
Спасибо за статью, приятно, когда автор умеет доносить сложное простым языком. Иногда требуется по работе вникнуть в технические процессы. Даже с недочётами этот материал ценен, по своей подаче, обязательно продолжайте. А развязавшаяся дискуссия только подтверждает это. Принимайте во внимание критику, как точки роста, а на выпады не обращайте внимание. Жду следующий материал.
Про монолиты немного не так. Они, как правило, имеют независимые части и разные слои. И разрабатываются независимыми командами. Чаще имеют общую базу данных, которая позволяет минимизировать число распределенных транзакций и снимает боль с косистентностью. Минусы - релизы и сложности (не невозможность) с горизонтальным масштабированием. Часто у каждой команды так же свой релиз и часто на ежедневной основе. Большинство слоёв легко горизонтально масштабируются.
Самое весёлое, что из монолита часто начинают выделять микросервисы, а микросервис за несколько лет имеет шанс стать монолитом. Это нормально.
Не нормально, когда на старте небольшого проекта с одним бэкэнд разработчиком проект делят на 6 микросервисов, сроки с 3-х месяцев сдвигаются на полтора года, один он уже не может вывозить, а ценность остаётся не проверенной. Регулярно наблюдаю закрытие таких архитектурно красивых проектов.
Сложное — просто: архитектуры ПО на жизненных примерах