Как стать автором
Обновить

Рациональный подход к декомпозиции систем на модули или микросервисы. Практика

Уровень сложностиСложный
Время на прочтение12 мин
Количество просмотров4.8K
Всего голосов 12: ↑9 и ↓3+6
Комментарии2

Комментарии 2

Снова убеждаюсь, что половина квалификации Аналитика / Архитектора в умении внятно высказывать свои мысли и адаптироваться к любой аудитории. С этим у автора плоховато.

По диагонали статью читать невозможно. Связать со своим опытом невозможно.

Приходится лезть в детали. А это по вашей же системе оценок плохо.

Есть ощущение, если провести декомпозицию будущей системы сверху вниз в том же столетнем idef0, то мы получим:

1) функции системы

2) кол-во связей функций между друг другом

из чего мы можем получить первичную оценку, что, куда и как можно отнести.

И еще нюанс или вопрос: как так получилось, что api появилось до декомпозиции ?

Флаг прочтения есть только у персональных уведомлений. Уведомления отправляются разными экторами в разное время — персональные отправляются системой автоматически, а новостные — по запросу администратора. Они отправляются разным людям — персональные отправляются водителю, создавшему точку, а новостные — всем водителям. Даже методы API для отправки используются разные.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий