Статья выглядит как хейт монолитных решений "в общем случае": для монолитов минусы выставляются, плюсы же заметаются под ковёр. Для микросервисов та же картина, но ровно наоборот: плюсы выпячиваются, минусы заметаются под ковёр.
С таким подходом можно легко влететь в ситуацию "микросервисного монолита", когда исключается главное достоинством микросервиса - заменяемость, при этом недостатки в виде высокой связности остаются. Зато обилие связей сервисов и необходимость обслуживания связей путём внедрения всяких мониторингов и прочих вспомогательных компонентов со своими связями ведёт к повышению хрупкости системы. Ну и поддержание обозримости системы в целом - тоже та ещё задача (схема БД одного сервиса простая, ага, а вот количество неявных связей между БД разных сервисов может очень сильно порадовать глаз в случае рефакторингов схем данных).
И да, монолит (в смысле все связи - in-process) тоже может быть модульным с нормальной архитектурой.
Этот вопрос не про знание или незнание названия нотации а про то, что надо иметь хотя бы какую-то теоретическую базу, чтобы хоть где-то это понятие встретилось в письменном виде.
Минимизироваться должна связка {количество компонентов, сложность каждого компонента, количество связей конкретного компонента, общее количество связей, длина пути между функционально связанными компонентами, наверняка что-то ещё}.
Архитектуру можно считать относительно успешной, если интегральный рост этих метрик медленнее, чем функциональность проекта.
Дальше может быть дискуссия как это всё считать, но я бы не хотел открывать этот ящик Пандоры.
В ядре любой ОС это основная концепция для реализации полиморфных объектов, коих пруд пруди даже в ядре. Например, попробуйте реализовать поддержку разных файловых систем без этого. Да хотя бы файловой системы с каталогами и файлами.
Вы таки считаете, что ситуации, когда это может понадобиться, не может быть?
Пример: многопользовательское приложение, для разных групп пользователей нужно по-разному предоставлять сервисы через DI. Билдер определяет правила для фабрики, которая будет создавать на каждого пользователя свой дочерний контейнер.
Ох, доводилось мне видеть компоненты, которые писали джуны "на один раз", которые (джуны в смысле) сбегали через годика полтора-два. Собственно, если ты раз в два года меняешь работу в очередной стартап, то не просто успеваешь застать долгоживующие компоненты.
ООП, ФП с монадами, SOLID и прочие практики нужны для того, чтобы в первую очередь управлять сложностью. И они не приносят пользы при отсутствии сложности. Поэтому нет смысла приводить примеры, где нет сложности - они будут абсурдными. Что и получилось в этой статье.
Хантинг в вузах имеет место быть и имеет свои плюсы и минусы для всех сторон, но плюсов в среднем больше: толковые скромные получат работу, работодатель экономит на отборе и, возможно, на подготовке, препода тоже можно прикармливать каким-то образом кроме морального удовлетворения.
Минусы тоже есть, но они, скорее, ситуативные: меньшая инициативность тех, кто уже пристроен, злые языки могут препода назвать продающим рабов, пролетающие могут иметь зуб на него и т.п.
Статья выглядит как хейт монолитных решений "в общем случае": для монолитов минусы выставляются, плюсы же заметаются под ковёр. Для микросервисов та же картина, но ровно наоборот: плюсы выпячиваются, минусы заметаются под ковёр.
С таким подходом можно легко влететь в ситуацию "микросервисного монолита", когда исключается главное достоинством микросервиса - заменяемость, при этом недостатки в виде высокой связности остаются. Зато обилие связей сервисов и необходимость обслуживания связей путём внедрения всяких мониторингов и прочих вспомогательных компонентов со своими связями ведёт к повышению хрупкости системы. Ну и поддержание обозримости системы в целом - тоже та ещё задача (схема БД одного сервиса простая, ага, а вот количество неявных связей между БД разных сервисов может очень сильно порадовать глаз в случае рефакторингов схем данных).
И да, монолит (в смысле все связи - in-process) тоже может быть модульным с нормальной архитектурой.
Этот вопрос не про знание или незнание названия нотации а про то, что надо иметь хотя бы какую-то теоретическую базу, чтобы хоть где-то это понятие встретилось в письменном виде.
С этого и надо было начинать. И не продолжать.
Точно то же самое можно говорить и про медиков, но стрёмно, авось припомнят.
Минимизироваться должна связка {количество компонентов, сложность каждого компонента, количество связей конкретного компонента, общее количество связей, длина пути между функционально связанными компонентами, наверняка что-то ещё}.
Архитектуру можно считать относительно успешной, если интегральный рост этих метрик медленнее, чем функциональность проекта.
Дальше может быть дискуссия как это всё считать, но я бы не хотел открывать этот ящик Пандоры.
... а потом не запутаться в их композировании обратно
Что-то созвучное с анекдотом "Разум на Земле - величина постоянная. А население растёт."
Скорее так: слишком простой код вряд ли будет полезным.
В ядре любой ОС это основная концепция для реализации полиморфных объектов, коих пруд пруди даже в ядре. Например, попробуйте реализовать поддержку разных файловых систем без этого. Да хотя бы файловой системы с каталогами и файлами.
Вы таки считаете, что ситуации, когда это может понадобиться, не может быть?
Пример: многопользовательское приложение, для разных групп пользователей нужно по-разному предоставлять сервисы через DI. Билдер определяет правила для фабрики, которая будет создавать на каждого пользователя свой дочерний контейнер.
https://habr.com/ru/articles/258825/
Если начинать любой проект с вот этого, получится примерно то же самое:
-- мне просто надо сложить два числа!
-- подожди, надо сначала определиться с концепцией числа!
А Вы уверены, что то решение не было написано чьей-то кровью на стене?
Особенно если на ящиках нормально написано, что в них лежит.
Ох, доводилось мне видеть компоненты, которые писали джуны "на один раз", которые (джуны в смысле) сбегали через годика полтора-два. Собственно, если ты раз в два года меняешь работу в очередной стартап, то не просто успеваешь застать долгоживующие компоненты.
ООП, ФП с монадами, SOLID и прочие практики нужны для того, чтобы в первую очередь управлять сложностью. И они не приносят пользы при отсутствии сложности. Поэтому нет смысла приводить примеры, где нет сложности - они будут абсурдными. Что и получилось в этой статье.
Хантинг в вузах имеет место быть и имеет свои плюсы и минусы для всех сторон, но плюсов в среднем больше: толковые скромные получат работу, работодатель экономит на отборе и, возможно, на подготовке, препода тоже можно прикармливать каким-то образом кроме морального удовлетворения.
Минусы тоже есть, но они, скорее, ситуативные: меньшая инициативность тех, кто уже пристроен, злые языки могут препода назвать продающим рабов, пролетающие могут иметь зуб на него и т.п.
Вот и славно, что мы придерживаемся одного мнения.
Вы видите в этом что-то плохое?
Вот только симпатичная девочка имеет исключительно меркантильные интересы.
Как только клиент на борту - он становится исключительно статистической единицей.
Выглядит будто у девушки запасная жизнь есть...
С другой стороны, разработчики на не-мейнстримных языках с претензиями готовы говорить об этом постоянно.
Скрытый текст