Очень странная идея. Идея как раз в том, что для объекта известно, какие именно сообщения он может обрабатывать, но не известно, как именно. Если структура сообщения неизвестна получателю, то как он может его обработать?
Вообще для отправки сообщений не нужны никакие очереди, сообщения могут отправляться (и обрабатываться) и мгновенно (как в http или в том же Smalltalk). ООП никак не противоречит системам реального времени, более того, активно в них используется.
Хм, вообще в ООП как раз тип сообщения - известен. ООП (еще со времен smalltalk) про объединение данных и методов с ними работы. Методы работы - да, можно описывать как отправку сообщений. Важно, что у конкретного объекта известно, какие сообщения он может принимать и при отправке - не важно и даже не известно, как именно они будут обрабатываться. IoC - это поздний паттерн, ООП может быть и без IoC.
А почему "внутренний кэш" мешает горизонтальному масштабированию, а внешний - "легко горизонтально масштабируется"? Это совершенно не верно, тип кэша никак не связан с простотой масштабирования. Более того, все приведенные примеры для внешних кэшей (Тарантул, Редис) не масштабируются горизонтально. А вот вполне себе внутренний Хазелкаст - как раз масштабируется.
И подобных неточностей в статье довольно много, кажется, что автор не очень хорошо понимает, как и для чего нужно кэширование и просто пересказывает википедию. Для студента или стажера - достаточно. Для миддла - уже категорически недостаточно информации и понимания. К сожалению, в статье нигде не указано, что она для студентов.
В статье очень много как опечаток и неточностей, так и фактических ошибок и неверных советов. Для практической работы - статья скорее вредная. Для прохождения собеседований - может помочь, если собеседующий тоже никогда не занимался системным дизайном.
Такой нет и быть, увы, не может. Системный дизайн - не какая-то дисциплина, а просто тип собеседований в некоторых компаниях. Есть литература по архитектуре, есть много разных практик по конкретным направлениям, но все это недостаточно для даже очень базовой практики.
Тебе для проектирования или для прохождения интервью? Обычно книжки, пригодные для одного - не пригодны для другого. Фундаментальных книг, увы, нет, так как нет фундамента. Есть множество книжек по архитектуре, но все они бесполезны без реального практического опыта (да и с ним далеко не все полезны). Для собеседований - надо читать ту книжку, которую читал конкретный интервьюер. Обычно это Алекс Чу. Для реальной работы книжки по интервью - бесполезны (скорее даже вредны)
Хм, очень странная мыль, что у компании-владельца нет изолированных процессов ) Вот у банка эмиссия и эквайринг - чем связаны? Вот внутри T-банка продукт "доступ к бизнес-залам" как связан с остальными продуктами? Там общих данных - clientId и все.
Я не увидел там аргументации за МСА. Поправь, но я видел следующий набор утверждений 1) Проблемы легаси в процессах и людях 2) При внедрении МСА придется перестраивать и процессы и людей 3) Поэтому в МСА лучше с частотой выкладки.
Первое и второе утверждение - верны. Но вот пункт 3 никак и неоткуда не следует. И ниоткуда не следует, что переписать проект на модульный монолит или другой арх.стиль не решит тех же проблем с людьми и сервисами.
Хм, а где тут "один продукт"? И, заметим, тут все равно ты пишешь про примерно 100 человек, которые занимались этим софтом.
И да, я проводил довольно много разных арх.рефакторингов в очень разных окружениях. Да, это сложно. Но вполне реализуемо и внутри монолита. Но да, проблемы - не инженерные, а процессные в первую очередь. И решаются на этом уровне. А МСА - не при чем.
Так переписывание на другой монолит решит ровно те же проблемы (или не решит, так как менеджеры те же самые и разработчики те же самые и архитекторы те же самые - откуда изменение-то будет?) В любом случае для решения проблемы "релиз занимает 3 года" нужно перестраивать всю компанию (начиная от бизнеса, кстати). И какой там будет арх.стиль внутри - пофиг.
Хм, почему-то у меня были монолиты, в которых автотесты покрывали все бизнес-функции и отрабатывали за единицы часов. Тестировать монолит - проще, нежели распределенную систему. И если почему-то не справились даже с тестами для монолита - то тем более не справятся с тестом распределенной системы.
Хм, я вполне себе понимаю, как это работает с точки зрения бизнеса. Но там вообще не важен МСА, важны так или иначе автономные команды. Но автономность команд не связана с МСА, а связана с выстраиванием процессов и с entrerpise и solution архитектурой, с управлением знаниями и так далее.
Хм, разные продукты - это как раз про отсутствие необходимости в активном обмене данными, в бизнес-транзакциях и так далее. Да, выделение продуктов (доменов) - не тривиальная задача, но в этом и есть работа архитектора.
Ну, для планирования и координации сотен человек на единицы лет - TOGAF не обязателен, там и простого проектного офиса хватает. Точные границы применимости TOGAF - сложно описать, это же не жесткий фреймворк, а скорее набор концепций, из которых можно построить то, что нужно под задачу.
Это про разные вещи. Просто любой бизнес - это всегда про неопределенность. Никто не может гарантированно ответить ни про планируемые ФТ, ни про целевые НФТ. Но хороший архитектор, разбирающейся в предметной области - может, задавая бизнесу правильные вопросы, уточнить границы неопределенности и, исходя из этого, проектировать архитектуру.
А аргументация для точки зрения есть? Каким образом МСА (и что под ней понимаете, кстати - у термина плохо с общепринятым определением) помогает частоте релизов? За счет чего?
А расскажи, когда один продукт - делает команда больше 100 человек? Который нет смысла разделить на несколько разных продуктов, независимых по процессам, данным, бизнес-транзакциям и так далее.
Так для распределенных систем (тех же МСА) нужны более компетентные специалисты. А если есть нормальные архитекторы, то без разницы, модули или микросервисы, все вполне себе контролируется.
Очень странная идея. Идея как раз в том, что для объекта известно, какие именно сообщения он может обрабатывать, но не известно, как именно. Если структура сообщения неизвестна получателю, то как он может его обработать?
Вообще для отправки сообщений не нужны никакие очереди, сообщения могут отправляться (и обрабатываться) и мгновенно (как в http или в том же Smalltalk).
ООП никак не противоречит системам реального времени, более того, активно в них используется.
Хм, вообще в ООП как раз тип сообщения - известен. ООП (еще со времен smalltalk) про объединение данных и методов с ними работы. Методы работы - да, можно описывать как отправку сообщений. Важно, что у конкретного объекта известно, какие сообщения он может принимать и при отправке - не важно и даже не известно, как именно они будут обрабатываться.
IoC - это поздний паттерн, ООП может быть и без IoC.
А почему "внутренний кэш" мешает горизонтальному масштабированию, а внешний - "легко горизонтально масштабируется"? Это совершенно не верно, тип кэша никак не связан с простотой масштабирования. Более того, все приведенные примеры для внешних кэшей (Тарантул, Редис) не масштабируются горизонтально. А вот вполне себе внутренний Хазелкаст - как раз масштабируется.
И подобных неточностей в статье довольно много, кажется, что автор не очень хорошо понимает, как и для чего нужно кэширование и просто пересказывает википедию. Для студента или стажера - достаточно. Для миддла - уже категорически недостаточно информации и понимания. К сожалению, в статье нигде не указано, что она для студентов.
В статье очень много как опечаток и неточностей, так и фактических ошибок и неверных советов. Для практической работы - статья скорее вредная.
Для прохождения собеседований - может помочь, если собеседующий тоже никогда не занимался системным дизайном.
Такой нет и быть, увы, не может. Системный дизайн - не какая-то дисциплина, а просто тип собеседований в некоторых компаниях.
Есть литература по архитектуре, есть много разных практик по конкретным направлениям, но все это недостаточно для даже очень базовой практики.
Тебе для проектирования или для прохождения интервью? Обычно книжки, пригодные для одного - не пригодны для другого.
Фундаментальных книг, увы, нет, так как нет фундамента. Есть множество книжек по архитектуре, но все они бесполезны без реального практического опыта (да и с ним далеко не все полезны).
Для собеседований - надо читать ту книжку, которую читал конкретный интервьюер. Обычно это Алекс Чу. Для реальной работы книжки по интервью - бесполезны (скорее даже вредны)
Понятно, никаких аргументов нет.
Хм, очень странная мыль, что у компании-владельца нет изолированных процессов )
Вот у банка эмиссия и эквайринг - чем связаны?
Вот внутри T-банка продукт "доступ к бизнес-залам" как связан с остальными продуктами? Там общих данных - clientId и все.
Я не увидел там аргументации за МСА. Поправь, но я видел следующий набор утверждений
1) Проблемы легаси в процессах и людях
2) При внедрении МСА придется перестраивать и процессы и людей
3) Поэтому в МСА лучше с частотой выкладки.
Первое и второе утверждение - верны.
Но вот пункт 3 никак и неоткуда не следует. И ниоткуда не следует, что переписать проект на модульный монолит или другой арх.стиль не решит тех же проблем с людьми и сервисами.
Хм, а где тут "один продукт"? И, заметим, тут все равно ты пишешь про примерно 100 человек, которые занимались этим софтом.
И да, я проводил довольно много разных арх.рефакторингов в очень разных окружениях. Да, это сложно. Но вполне реализуемо и внутри монолита. Но да, проблемы - не инженерные, а процессные в первую очередь. И решаются на этом уровне. А МСА - не при чем.
И, кстати, не думаю, что у меня меньше опыта )
Так переписывание на другой монолит решит ровно те же проблемы (или не решит, так как менеджеры те же самые и разработчики те же самые и архитекторы те же самые - откуда изменение-то будет?)
В любом случае для решения проблемы "релиз занимает 3 года" нужно перестраивать всю компанию (начиная от бизнеса, кстати). И какой там будет арх.стиль внутри - пофиг.
Хм, почему-то у меня были монолиты, в которых автотесты покрывали все бизнес-функции и отрабатывали за единицы часов.
Тестировать монолит - проще, нежели распределенную систему. И если почему-то не справились даже с тестами для монолита - то тем более не справятся с тестом распределенной системы.
Хм, я вполне себе понимаю, как это работает с точки зрения бизнеса. Но там вообще не важен МСА, важны так или иначе автономные команды. Но автономность команд не связана с МСА, а связана с выстраиванием процессов и с entrerpise и solution архитектурой, с управлением знаниями и так далее.
Хм, разные продукты - это как раз про отсутствие необходимости в активном обмене данными, в бизнес-транзакциях и так далее.
Да, выделение продуктов (доменов) - не тривиальная задача, но в этом и есть работа архитектора.
Ну, для планирования и координации сотен человек на единицы лет - TOGAF не обязателен, там и простого проектного офиса хватает. Точные границы применимости TOGAF - сложно описать, это же не жесткий фреймворк, а скорее набор концепций, из которых можно построить то, что нужно под задачу.
Это про разные вещи.
Просто любой бизнес - это всегда про неопределенность. Никто не может гарантированно ответить ни про планируемые ФТ, ни про целевые НФТ. Но хороший архитектор, разбирающейся в предметной области - может, задавая бизнесу правильные вопросы, уточнить границы неопределенности и, исходя из этого, проектировать архитектуру.
А аргументация для точки зрения есть?
Каким образом МСА (и что под ней понимаете, кстати - у термина плохо с общепринятым определением) помогает частоте релизов? За счет чего?
А расскажи, когда один продукт - делает команда больше 100 человек?
Который нет смысла разделить на несколько разных продуктов, независимых по процессам, данным, бизнес-транзакциям и так далее.
Так для распределенных систем (тех же МСА) нужны более компетентные специалисты. А если есть нормальные архитекторы, то без разницы, модули или микросервисы, все вполне себе контролируется.