вы опять передергиваете. гражданская позиция тут ни при чем. Дело только в том, чем вы жертвуете и что получаете взамен. Но я повторю: для ремесленника это заведомо проигрышный вариант.
Это путь война. Воин и без ваших призывов никуда не уедет. Вы манипулируете, когда ставите война в пример ремесленникам. Для ремесленников это заведомо проигрышный вариант.
Есть такой термин "смалодушничать". Но смалодушничать можно просто из-за отсутствия опыта подобных ситуаций. При получении необходимого опыта человек будет дейстовать быстро и решительно, а его мораль не будет подвергаться испытаниям, потому что он в прошлый раз уже все для себя решил. Я был в подобной ситуации.
Т.е. в теории это должно работать, но на практике становится только хуже. Практически это выражется в том что пока мидлы не знают про солид, они пишут простой говнокод, а после знакомства сложный.
Два вопроса: 1 как реализована надёжная публикация событий при изменении агрегатов? 2 зачем вам версия агрегата если команды имеет смысл накатывать только на самую последнюю версию по очереди?
Ваш вопрос слабо связан с сутью статьи. Темы которые вы понимаете не зависят от стиля. Основное отличие ООП от процедурного подхода это наличие явной модели в коде. Приверженность к ООП сама по себе не даёт чудесным образом возможности строить удобные и гибкие модели с первой попытки. Техническая часть ДДД в общем и агрегаты в частности это набор подходов, который через доп ограничения адаптирует ООП для использования на бэкенде. Вопросы которые вы поднимаете это традиционный источник разочарования в ООП. Разработка удобной модели это доп оверхэд, по сравнению с процедурным подходом, когда вы можете начинать хачить без подготовки.
мы с вами очень по разному видим как все устроено, я уже задал контекст описав, что документация нужна и у вас есть очень хороший разработчик. Вам уже повезло, очень маловероятно найти такого же только с перламутровыми пуговицами. Я считаю, что в этом контексте нет «хорошего» решения при котором разработчик разрулит ситуацию сам. Когда вы обязываете его самого найти решение проблемы, вы теряете. А как раз задача руководителя минимизировать потери, повысить эффективность и далее по списку. Накину, вы плохой руководитель, т.к. рост производительности команды ограничен догмами, которые вы приняли на веру только потому что источник имеет громкое название.
пример придумал. есть отличный разработчик, который качественно и быстро разрабатывает, но отвратительно пишет формальные тексты, а на английском и того хуже. Но надо написать документацию к той функциональности, которую он несколько месяцев делал. Ваши действия?
я просил примеры. мой опыт как то сильно расходится с тем, что написано в статье. Ниже VFaland написал, что он человек-оркестр, который затыкает дыры, хотя это и плохой пример, но более жизненный и близкий мне.
Ребятки получили чувство глубокого удовлетворения
Это мой вклад в борьбу с манипулированием
все верно, это эгоизм, я не вижу общества ради которого я хочу жертвовать своими интересами. И не "многие" а абсолютное подавляющее большинство
вы опять передергиваете. гражданская позиция тут ни при чем. Дело только в том, чем вы жертвуете и что получаете взамен. Но я повторю: для ремесленника это заведомо проигрышный вариант.
Это путь война. Воин и без ваших призывов никуда не уедет. Вы манипулируете, когда ставите война в пример ремесленникам. Для ремесленников это заведомо проигрышный вариант.
Строительство того что мы сейчас имеем, началось при Путине
Есть такой термин "смалодушничать". Но смалодушничать можно просто из-за отсутствия опыта подобных ситуаций. При получении необходимого опыта человек будет дейстовать быстро и решительно, а его мораль не будет подвергаться испытаниям, потому что он в прошлый раз уже все для себя решил. Я был в подобной ситуации.
Есть небольшой нюанс с этим определением, understandable и flexible это противоречащие друг другу требования
Можете разврнуть вот эту мысль "Диски в адаптере. Внимание! Не используйте в настоящих серверах! Для этого есть форм-факторы получше" ? у меня как раз сервер и я планировал поставить в него такую конструкцию AOC-SLG3-2M2 | Add-on Cards | Accessories | Products - Super Micro Computer, Inc.
Т.е. в теории это должно работать, но на практике становится только хуже. Практически это выражется в том что пока мидлы не знают про солид, они пишут простой говнокод, а после знакомства сложный.
так это возможно только если код раздроблен до состояния атомов
Если не хамить соискателям, то и обижаться не придется. А так действия кандидата вполне соответствуют действиям ревьюера. Счёт один один ;)
Из текста я понял, что автору зачем но нужны старые версии
Два вопроса: 1 как реализована надёжная публикация событий при изменении агрегатов? 2 зачем вам версия агрегата если команды имеет смысл накатывать только на самую последнюю версию по очереди?
Чем это лучше кафки?
Ваш вопрос слабо связан с сутью статьи. Темы которые вы понимаете не зависят от стиля. Основное отличие ООП от процедурного подхода это наличие явной модели в коде. Приверженность к ООП сама по себе не даёт чудесным образом возможности строить удобные и гибкие модели с первой попытки. Техническая часть ДДД в общем и агрегаты в частности это набор подходов, который через доп ограничения адаптирует ООП для использования на бэкенде. Вопросы которые вы поднимаете это традиционный источник разочарования в ООП. Разработка удобной модели это доп оверхэд, по сравнению с процедурным подходом, когда вы можете начинать хачить без подготовки.