реализуй сервис по CQRS + EventSourcing c такими-то требованиями
Если наступить себе на горло (потому что будет лукавство сказать что я просто разработчик), то я вам могу ответить что
Вы крадёте инженерную составляющую у разрабов, говоря как делать. Большинство разрабов с высшим образованием. Уже давно нет профессии кодера из бурсы и т.п. Это их работа и компетенции выбирать будут они делать CQRS или нет.
Вы так рассуждаете, потому что хотите на галере занять место не на вёслах, а указвая как грести. Я может открою тайну, но везде всё одинаковое! Мы повторяем одну и туже работу для разных собственников, чтобы они имели конкурентное приемущество. Но все мы живём в одном одинаковом мире, с одинаковыми технологиями, с похожими ограничениями. Ничего уникального, как правило, аналитик не изыщит.
Есть блестящая книга "Фабрики разработки программ". Там есть ужасающая мысль - авторы замечают, что ещё с 80х индустрия проходит стадию ремесленичества и отчаяно нуждается в "индустриализации". Т.е. нужно не плодить людей "нужных", а использовать CI/CD, DDD, микросервисы, Agile и прочее.
Не мало таких людей, которые как и я не испытывают церебрального самоудовлетворения (как говорят физики) от кодинга. Не мало людей кому интересна предметка и её автоматизация/улучшение/автоматизация. Для нас не зазорно сделать всю работу самому, ещё и других научить/документацию оставить.
Не подумайте что я считаю только аналитиков бесполезными. Мой опыт работы и общения говорит о том что мы все бесполезны по большому счёту, т.к. не делаем чаще всего ничего (!) полезного, кроме как делаем кого-то более конкурентно способным....Правильнее будет даже сказать, что аналитики не бесполезны, в аспекте антагонизма работников/собственников, аналитик будет относится к прослойке надсмотрщиков, а поэтому просто не товарищи, когда вторгаются на чужую территорию без просьбы о помощи.
Статья круто началась, жизненно) Закончилась не про войну - про потасовки школоты на перемене)
Я бы докопался до того, что это описание взаимодействия команды ремесленников, которые стучат своими особенными молоточками, чтобы получить конечную заготовку (как булавка у Смита). У команды инженеров вышедший на индустриальный уровень "воинов" не бывает - в худшем случае банка пауков))
Выберите книгу, и с командой поэтапно пробуйте что-либо: спецификации, агрегаты, CQS, иммутабельные типы и т.д. Ошибкой будет пытаться сделать всё сразу, особенно в одиночку.
Дело как раз в освоении. Многие люди склонны подменять знания опытом. Часто это работает на благо. А когда не работает, нужно достучаться до человека, по-изучать какую-то тему. Под действием шовинизма, эти люди очень тяжело признают проблему.
Достоинство кандидатов 20 лет в том, что они чаще открыты для нового, не ограничены рамками, которые прочертил опыт. Но речь тут можно вести только о вероятности, правила никакого нет.
Навскидку, хотя не уверен что пример указный встречается, если только в момент бизнес-операции становится ясно что нужно догрузить, можно разбить эту операцию на две, оставив свою модель чистой и изолированной.
Мне видится это разница в дизайне - в какой момент сделать нужный запрос. Если в рамках транзакции (бизнес-метода агрегата) вы знаете что вам понадобятся данные, то значит метод агрегата должен принять эти данные до операции. Готов попробовать помочь с конкретными примерами.
Приветствую! Сложно будет вам ответить. По вашим статьям видно, что возможно вы начали штудировать Капитал. Удалось ли дочитать до конца? Спрашиваю потому, что вся статья целиком и есть ответ на ваш вопрос. Ответ пока могу дать пока приблизительный.
Виртуальный товар, это основной капитал, что-то похожее на фабрикат, с той разницей, что для превращения в товар такой продукт не требует (но может включать) вложения труда в каждую единицу. Потребление виртуального товара возможно только при условии того что у второй стороны есть средство потребления (компьютер, телевизор, телефон, 3D принтер и т.п.). Прибыль при этом возникает не из процесса производства, а из процесса обмена, что в корне меняет суть производственных отношений, не только по части нормы прибыли, но и по форме кооперации.
Пожалуйста, напишите ответ на мой вопрос, я тогда смогу более точно понять какой нужен вектор ответа.
В нашем случае, только изменившиеся объект значения попадают в шину доменных событий. Однако, вполне возможно, что другой организации будет больше подходить другая форма обмена: агрегатами целиком или только изменившимися атрибутами.
А вы не считаете что хорошие микросервисы — это декомпозированные по субдомену (с запиханным DDD), будут бизнесу подходить лучше других?
В этом вопросе в очень многих руководствах, книгах, докладах коллег встречал что это совершенно не разные вещи. А если для вас по другому, объясните пожалуйста!
Впрочем, соглашусь что тема становиться объектом инфо-бизнеса.
Говорить в лицо или в комментарии я буду одинаково! Считайте, что я систематически плохо отношусь к генералам из описанной вами сказки. Вот только генералов вы как то странно определили!?
Хамство используют по определению для того чтобы продемонстрировать своё превосходство, свой шовинизм. А я же считаю, что за мнениями и утверждениями люди невольно скрывают свои частные интересы (см. критику идеологии). Считаю что как минимум отчасти статья и ваши утверждения реакционны и противоречит ряду принципов Agile и Scrum. В этом вопросе я ни за себя, ни за вас — за тех кто делает реальную работу.
базируется на принципе распределения обязанностей, присущему экономическим отношениям в эпоху капитализма и описанного в экономической науке еще в XVIII веке
Читал и много. Рад вам сообщить, scrum — форма кооперации нетоварных производственных отношений, которому прежние принципы (как разделение труда) мешают.
Моей команде коучи не нужны. А начальников с "авторитарным стилем" сильная команда оставит в одиночестве.
Скрам-гайд описывает как работает команда
Лично у меня тогда претензии к упоминанию скрама в этом материале.
Откуда команда берет новых людей?
Работу HR'ов конечно не делаем, но интервью провести можем.
Ищет и учит сама?
Да, внутри обучение мы организуем сами, пытаемся создавать условия для того чтобы такое обучение имело свои плоды.
А откуда берутся заказчики? А откуда у команды берутся производственные цели?
Вы их тоже не находите — вас находит "человек" с деньгами и вы за зарплату общаетесь с заказчиками. А вот если себя не обманывать, то производственные цели будут совпадать с целями организации, не правда ли? Нужен отдельный человек который их перепишет?
И таких моментов выходящих за рамки того что делает скрам-команда можно на войну и мир перечислить.
Нет таких моментов. Для Scrum и XP есть некоторое множество подходящих задач. Если коротко: это массовый продукт и вы изначально не знаете что именно нужно пользователю (потому что пользователь и сам не знает). ВСЁ!!! См.подробнее.
Ваша сентенция о неполноценности скрам-команды базируется на социал-дарвинизме или том что вам самому выгоднее разделять функциональные обязанности и усиливать эксплуатацию ваших сотрудников?
Но почему-то большинство практиков Agile согласны скорее с утверждением что самоуправление лучше всего работает если границы этого самого самоуправления четко установлены.
Вы просто не понимаете что это не вопрос вашего таланта или софтскилов, а вопрос денег. Вы понимаете почему существуют стартапы которыми управляют люди вообще без опыта?
А в SCRUM точно есть то что вы в статье написали?
SCRUM, XP — горизонтальные практики, которым нужно чтобы люди были вовлечены, т.е. наименее отчуждены в процессе труда. А вот метноры, коучеры, психологи, управленцы — это пережиток прошлых производственных отношений, в которых эти фреймворки не работают.
Вопрос про стили управления вообще к SCRUM не могут иметь отношения.
Стрённый материал, который говорит о положении дел в компании.
Вы сравняли паттерны доменной логики с парадигмой. Между тем, очень и очень многие системы начинаются одинаково, но в ходе своего развития вырисовываются какие-то конкретные.
Вы путаете технологии и паттерны доменной логики. Агрегат вполне можно даже разместить в РСУБД (конечно это будет значительным извращением). Технологии в этой задаче вторичны — дело в парадигме декомпозиции.
Когда человек что-то утверждает, чаще всего он за своим отношением скрывает собственные интересы. Вам просто удобно что такой человек есть.
Я с вами не согласен.
MishaTheSlayer Системный аналитик
Это ваш хлеб — конечно вы не согласны. А я нахожусь с другой стороны, не согласен с вами. В какой-то мере, это вопрос к разработчикам. Или они ведут себя как инженеры и сами драйвят разработку, или как специалисты по кодингу без каких-либо претензий, в т.ч. зарплатных. Но как бы там ни было, в большинстве проектов аналитик выдуманная профессия, нужная настолько же, насколько нужен продавец на кассе крупного ретейлера. Код пишут программисты — это реальный труд, а 10 менеджеров над двумя программистами — это трэш.
Если наступить себе на горло (потому что будет лукавство сказать что я просто разработчик), то я вам могу ответить что
Вы крадёте инженерную составляющую у разрабов, говоря как делать. Большинство разрабов с высшим образованием. Уже давно нет профессии кодера из бурсы и т.п. Это их работа и компетенции выбирать будут они делать CQRS или нет.
Вы так рассуждаете, потому что хотите на галере занять место не на вёслах, а указвая как грести. Я может открою тайну, но везде всё одинаковое! Мы повторяем одну и туже работу для разных собственников, чтобы они имели конкурентное приемущество. Но все мы живём в одном одинаковом мире, с одинаковыми технологиями, с похожими ограничениями. Ничего уникального, как правило, аналитик не изыщит.
Есть блестящая книга "Фабрики разработки программ". Там есть ужасающая мысль - авторы замечают, что ещё с 80х индустрия проходит стадию ремесленичества и отчаяно нуждается в "индустриализации". Т.е. нужно не плодить людей "нужных", а использовать CI/CD, DDD, микросервисы, Agile и прочее.
Не мало таких людей, которые как и я не испытывают церебрального самоудовлетворения (как говорят физики) от кодинга. Не мало людей кому интересна предметка и её автоматизация/улучшение/автоматизация. Для нас не зазорно сделать всю работу самому, ещё и других научить/документацию оставить.
Не подумайте что я считаю только аналитиков бесполезными. Мой опыт работы и общения говорит о том что мы все бесполезны по большому счёту, т.к. не делаем чаще всего ничего (!) полезного, кроме как делаем кого-то более конкурентно способным....Правильнее будет даже сказать, что аналитики не бесполезны, в аспекте антагонизма работников/собственников, аналитик будет относится к прослойке надсмотрщиков, а поэтому просто не товарищи, когда вторгаются на чужую территорию без просьбы о помощи.
Статья круто началась, жизненно) Закончилась не про войну - про потасовки школоты на перемене)
Я бы докопался до того, что это описание взаимодействия команды ремесленников, которые стучат своими особенными молоточками, чтобы получить конечную заготовку (как булавка у Смита). У команды инженеров вышедший на индустриальный уровень "воинов" не бывает - в худшем случае банка пауков))
Выберите книгу, и с командой поэтапно пробуйте что-либо: спецификации, агрегаты, CQS, иммутабельные типы и т.д. Ошибкой будет пытаться сделать всё сразу, особенно в одиночку.
Спасибо что правильно меня поняли и за совет. Обязательно почитаю!
Я лично не знаком с работниками в сфере разработки, которые считают что за что-то вообще стоит бороться, зато готовы просто поменять место работы.
DDD просто инструмент. Предпринимать усилия стоит только ради команды, ради удовлетворения себя в труде.
Статья про распространение знаний между работниками. ЛД, такое как я его вижу, вообще не причём - оно продолжает где-то там косплеиться)
см. сюда
Я рассказываю о кружках, как о методе развития команды. Посетив конференцию, почитав две книги не освоить сложных тем всей командой.
Дело как раз в освоении. Многие люди склонны подменять знания опытом. Часто это работает на благо. А когда не работает, нужно достучаться до человека, по-изучать какую-то тему. Под действием шовинизма, эти люди очень тяжело признают проблему.
Достоинство кандидатов 20 лет в том, что они чаще открыты для нового, не ограничены рамками, которые прочертил опыт. Но речь тут можно вести только о вероятности, правила никакого нет.
Навскидку, хотя не уверен что пример указный встречается, если только в момент бизнес-операции становится ясно что нужно догрузить, можно разбить эту операцию на две, оставив свою модель чистой и изолированной.
А может возможно?
Мне видится это разница в дизайне - в какой момент сделать нужный запрос. Если в рамках транзакции (бизнес-метода агрегата) вы знаете что вам понадобятся данные, то значит метод агрегата должен принять эти данные до операции. Готов попробовать помочь с конкретными примерами.
Крутой дайджест! Спасибо!
Захотелось выпустить пару статей)
Приветствую! Сложно будет вам ответить. По вашим статьям видно, что возможно вы начали штудировать Капитал. Удалось ли дочитать до конца? Спрашиваю потому, что вся статья целиком и есть ответ на ваш вопрос. Ответ пока могу дать пока приблизительный.
Виртуальный товар, это основной капитал, что-то похожее на фабрикат, с той разницей, что для превращения в товар такой продукт не требует (но может включать) вложения труда в каждую единицу. Потребление виртуального товара возможно только при условии того что у второй стороны есть средство потребления (компьютер, телевизор, телефон, 3D принтер и т.п.). Прибыль при этом возникает не из процесса производства, а из процесса обмена, что в корне меняет суть производственных отношений, не только по части нормы прибыли, но и по форме кооперации.
Пожалуйста, напишите ответ на мой вопрос, я тогда смогу более точно понять какой нужен вектор ответа.
ИИ дадут ещё больше работы - это его награда.
В нашем случае, только изменившиеся объект значения попадают в шину доменных событий. Однако, вполне возможно, что другой организации будет больше подходить другая форма обмена: агрегатами целиком или только изменившимися атрибутами.
А вы не считаете что хорошие микросервисы — это декомпозированные по субдомену (с запиханным DDD), будут бизнесу подходить лучше других?
В этом вопросе в очень многих руководствах, книгах, докладах коллег встречал что это совершенно не разные вещи. А если для вас по другому, объясните пожалуйста!
Впрочем, соглашусь что тема становиться объектом инфо-бизнеса.
Об этом немного расскажу во второй части.
Говорить в лицо или в комментарии я буду одинаково! Считайте, что я систематически плохо отношусь к генералам из описанной вами сказки. Вот только генералов вы как то странно определили!?
Хамство используют по определению для того чтобы продемонстрировать своё превосходство, свой шовинизм. А я же считаю, что за мнениями и утверждениями люди невольно скрывают свои частные интересы (см. критику идеологии). Считаю что как минимум отчасти статья и ваши утверждения реакционны и противоречит ряду принципов Agile и Scrum. В этом вопросе я ни за себя, ни за вас — за тех кто делает реальную работу.
Читал и много. Рад вам сообщить, scrum — форма кооперации нетоварных производственных отношений, которому прежние принципы (как разделение труда) мешают.
Моей команде коучи не нужны. А начальников с "авторитарным стилем" сильная команда оставит в одиночестве.
Лично у меня тогда претензии к упоминанию скрама в этом материале.
Работу HR'ов конечно не делаем, но интервью провести можем.
Да, внутри обучение мы организуем сами, пытаемся создавать условия для того чтобы такое обучение имело свои плоды.
Вы их тоже не находите — вас находит "человек" с деньгами и вы за зарплату общаетесь с заказчиками. А вот если себя не обманывать, то производственные цели будут совпадать с целями организации, не правда ли? Нужен отдельный человек который их перепишет?
Нет таких моментов. Для Scrum и XP есть некоторое множество подходящих задач. Если коротко: это массовый продукт и вы изначально не знаете что именно нужно пользователю (потому что пользователь и сам не знает). ВСЁ!!! См.подробнее.
Ваша сентенция о неполноценности скрам-команды базируется на социал-дарвинизме или том что вам самому выгоднее разделять функциональные обязанности и усиливать эксплуатацию ваших сотрудников?
Вы просто не понимаете что это не вопрос вашего таланта или софтскилов, а вопрос денег. Вы понимаете почему существуют стартапы которыми управляют люди вообще без опыта?
А в SCRUM точно есть то что вы в статье написали?
SCRUM, XP — горизонтальные практики, которым нужно чтобы люди были вовлечены, т.е. наименее отчуждены в процессе труда. А вот метноры, коучеры, психологи, управленцы — это пережиток прошлых производственных отношений, в которых эти фреймворки не работают.
Вопрос про стили управления вообще к SCRUM не могут иметь отношения.
Стрённый материал, который говорит о положении дел в компании.
Привет! Правильно ли я понял, что у вас Shared Database в микросервисах?
Почему написал на ФБ что чушь.
Напишу скоро свою статью)
Это ваш хлеб — конечно вы не согласны. А я нахожусь с другой стороны, не согласен с вами. В какой-то мере, это вопрос к разработчикам. Или они ведут себя как инженеры и сами драйвят разработку, или как специалисты по кодингу без каких-либо претензий, в т.ч. зарплатных. Но как бы там ни было, в большинстве проектов аналитик выдуманная профессия, нужная настолько же, насколько нужен продавец на кассе крупного ретейлера. Код пишут программисты — это реальный труд, а 10 менеджеров над двумя программистами — это трэш.