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