На самом деле разница не очень большая. Ну вот взяли бы мы этот переиспользуемый код в виде большой библиотеки, а не сервиса, то мы бы поймали как минимум половину от всех имеющихся сейчас проблем.
Вероятно тогда стоит обозначить, что вы понимаете под термином «приложение», а что «проект». Потому что в нашем случае это всё одно большое приложение, состоящее из разных микросервисов и фронтовых модулей.
1. На мой взгляд у вас не учтено, кто будет ставить задачи с точки зрения бизнеса и как эти люди между собой общаются. См. закон Конвея — «Организации проектируют системы, которые копируют структуру коммуникаций в этой организации». Откуда часто вытекает паттерн BoundedContext
2. Глобальная или локальная область применения — опасная история. Правильно сделать глобальную фичу — это серьезные затраты. А неправильно — создать большой риск проблем развития в дальнейшем (вот прямо сейчас работаю над проектом, где был сделан глобальный сервис для хранения настроек всех сервисов, это повлекло очень много проблем, неочевидных в момент выбора такого решения). Поэтому часто бывает так, что фича может по смыслу и глобальная, но экономически нецелесообразно делать её таковой.
Во-первых совершенно не факт, что надо вообще хранить данные для повтора в самой кафке и тем более в виде исходного сообщения, которое мы не смогли обработать, но почему-то решили, что сможем правильно скопировать. Да, можно сказать, что вдруг БД недоступна, но тогда не надо уходить на повторы, надо просто вызывать инженеров и чинить БД.
Во-вторых часто публикуется «полное» идемпотентное событие, таким образом когда мы обработали сообщение Zoiee, то обрабатывать Zoё уже просто не нужно.
Как альтернативное решение:
1. Проблемные события сохраняем в спец-таблицу БД как ID + партишен + оффсет
2. Удаляем из неё старое сообщение, как пришло новое сообщение с тем же ID
Бонусы:
— Размер таблицы есть метрика рассинхронизации состояний, по ней можно настроить алерты
— Не уложняем картину в кафке, в которой не всегда можно красиво разделить доступ
— Можно запускать вручную повторные попытки потребления отдельных сообщений
— Можно устроить сколь угодно сложную логику повторных попыток
Интересно, а откуда пошло, что разработчик это кусок программиста, а не наоборот? Я вот всегда считал, что программирование это лишь часть разработки продукта, куда кроме программирования входит методическая проработка решения для предметной области, проектирование интерфейсов, работа с обратной связью от пользователей, например.
Если ЛПР за разовый рекорд увеличил регулярную зарплату, то проблема исключительно в неадекватности действий ЛПРа. И уж тем более непонятно, как из этого можно придумать увольнение стахановца.
KPI по доходности позиций не единственный. Вот эти все зависимости долгосрочной доходности это не про продажника вообще. В нашем случае, например, вообще не было таких требований по покрытию продажами неприбыльными для нас товарами нашей клиентской базы, только представленность в ассортименте на складе и в «шоу-руме».
По поводу «называть торговыми агентами» — как на рынке труда тогда это в сфере торговли компьютерным оборудованием называлось, так и пишу, может по нынешним меркам это неправильно, но было так.
PS: Такое ощущение, что я кого-либо заставляю управлять продажами неестественным для него образом. Конечно же нет, я рассказываю тот опыт, который у меня есть. Еще раз повторюсь, очевидно этот опыт не нужно бездумно пытаться во все места применить или тем более считать какой-то фундаментальной истиной.
1. И при чем же тут прибыль компании, при чем KPI для расчета уровня оплаты труда, если это практически прямые отношения поставщика и сотрудника? KPI в оплате труда это не компас, куда грести в целом по жизни, чтобы получить больше денег, это средство синхронизировать цели компании и оплату труда этой компанией. Указанный пример прямо говорит, что это вообще не про цели компании и не про обсуждаемые KPI.
2. Вас лично никто не заставляет разговаривать с продажником про прибыль. Я лишь рассказываю про свой опыт, как эти две темы удалось достаточно близко привязать, т.е. мотивировать менеджеров продаж продавать то, что приносит компании большую прибыль и это вполне бодро работало.
1. Не встречал чтобы премия за представленность товара была хоть сколько-то значима на фоне общего объема прибыли, хотя безусловно такое может быть, но минорный же кейс.
2. Это вообще для продажника ОЧЕНЬ гипотетическая прибыль, так что не может засчитываться. Вполне может быть, что по факту и в убыток влетите, т.к. уровень издержек прежний, а продаёте всё практически в себестоимость. Такими проектами надо очень качественно управлять и прибыль в такой ситуации будет генерить по сути не продажник, а управляющий проектом.
Всерьез обсуждать KPI на основе сего опуса точно не стоит.
Не вижу с точки зрения практики кардинальной разницы между требованиями от продажника в рамках одного из KPI:
1. Генерировать больше прибыли
2. Большего абсолютного объема продаж с высокой доходностью
Если не думалось, что продажи себестоимостью будут рулить.
Конкретно в нашем случае это была оптовая торговля компьютерным оборудованием и комплектующими, насколько помню, набор KPI был порядка 3-4 показателей в разные моменты времени.
Можно, например, категоризировать все товарные позиции на несколько уровней доходности для компании. Я видел это в работе, вполне жизнеспособная конструкция.
Если реальные требования и KPI не совпадают системно, то скорее всего надо бежать с такой работы, потому что у руководства раздвоение, а бизнес такое редко прощает.
Аж захотелось пообщаться с этим воображаемым Сашей. Обычно там тоже интересная история озвучивается. Типа того, что руководство само не понимает что хочет, меняет цели хоть каждую неделю, по настроению, и уровень оплаты не пойми от чего зависит. И тут начинаешь думать, а точно для компании полезно Сашу уволить или может всё-таки лучше его руководителя? А подозреваемый Саша при нормальном руководителе может взлтетит и обеспечит прекрасные бизнес-показатели как три средних сотрудника вместе взятых, раз он так легко любые поставленные KPI выполнял.
Ладно бы усталость. Тут вообще непонятно что считают мерилом работы. Часто замечаю странные оправдания руководства, которое не исполняет свою роль и вместо внятного измеримого определения, что хорошо, а что плохо, надо начинает находить и увольнять тех, кто «кажется плохо работает», и ведь именно «кажется», т.к. внятного и измеримого определения нет.
2. Глобальная или локальная область применения — опасная история. Правильно сделать глобальную фичу — это серьезные затраты. А неправильно — создать большой риск проблем развития в дальнейшем (вот прямо сейчас работаю над проектом, где был сделан глобальный сервис для хранения настроек всех сервисов, это повлекло очень много проблем, неочевидных в момент выбора такого решения). Поэтому часто бывает так, что фича может по смыслу и глобальная, но экономически нецелесообразно делать её таковой.
PS: А какие проблемы с перевариванием топиков и партишенов в кафке? Вроде это одна из самых масштабируемых систем потоковой обработки данных.
Во-первых совершенно не факт, что надо вообще хранить данные для повтора в самой кафке и тем более в виде исходного сообщения, которое мы не смогли обработать, но почему-то решили, что сможем правильно скопировать. Да, можно сказать, что вдруг БД недоступна, но тогда не надо уходить на повторы, надо просто вызывать инженеров и чинить БД.
Во-вторых часто публикуется «полное» идемпотентное событие, таким образом когда мы обработали сообщение Zoiee, то обрабатывать Zoё уже просто не нужно.
Как альтернативное решение:
1. Проблемные события сохраняем в спец-таблицу БД как ID + партишен + оффсет
2. Удаляем из неё старое сообщение, как пришло новое сообщение с тем же ID
Бонусы:
— Размер таблицы есть метрика рассинхронизации состояний, по ней можно настроить алерты
— Не уложняем картину в кафке, в которой не всегда можно красиво разделить доступ
— Можно запускать вручную повторные попытки потребления отдельных сообщений
— Можно устроить сколь угодно сложную логику повторных попыток
Думаю тут MIT это всё-таки Мадрасский технологический институт
По поводу «называть торговыми агентами» — как на рынке труда тогда это в сфере торговли компьютерным оборудованием называлось, так и пишу, может по нынешним меркам это неправильно, но было так.
PS: Такое ощущение, что я кого-либо заставляю управлять продажами неестественным для него образом. Конечно же нет, я рассказываю тот опыт, который у меня есть. Еще раз повторюсь, очевидно этот опыт не нужно бездумно пытаться во все места применить или тем более считать какой-то фундаментальной истиной.
2. Вас лично никто не заставляет разговаривать с продажником про прибыль. Я лишь рассказываю про свой опыт, как эти две темы удалось достаточно близко привязать, т.е. мотивировать менеджеров продаж продавать то, что приносит компании большую прибыль и это вполне бодро работало.
1. Не встречал чтобы премия за представленность товара была хоть сколько-то значима на фоне общего объема прибыли, хотя безусловно такое может быть, но минорный же кейс.
2. Это вообще для продажника ОЧЕНЬ гипотетическая прибыль, так что не может засчитываться. Вполне может быть, что по факту и в убыток влетите, т.к. уровень издержек прежний, а продаёте всё практически в себестоимость. Такими проектами надо очень качественно управлять и прибыль в такой ситуации будет генерить по сути не продажник, а управляющий проектом.
Не вижу с точки зрения практики кардинальной разницы между требованиями от продажника в рамках одного из KPI:
1. Генерировать больше прибыли
2. Большего абсолютного объема продаж с высокой доходностью
Если не думалось, что продажи себестоимостью будут рулить.
Конкретно в нашем случае это была оптовая торговля компьютерным оборудованием и комплектующими, насколько помню, набор KPI был порядка 3-4 показателей в разные моменты времени.