Ну это риски, которые потом закладываются в стоимость часа... но речь не о том, в общем Речь о том, что хорошее ТЗ сильно облечило бы работу всем с такими заказчиками. И решило бы много "ой мы забыли" проблем изначально. То, что никто не хочет делать хорошее ТЗ, ибо это очень долго и дорого... это уже другой вопорос

ну вот кто-то решает эту проблему через ТЗ, кто-то через event storming, кто-то через стори мэппинги и т.д.

я не уверен что подробное ТЗ как-то спасает в ситуациях когда у тебя много стэкхолдеров и процессы которые тебе надо автоматизировать плохо формализованы сами по себе. А ждать пол года пока формализуют процессы смысла нет - можно пока формализуют процессы одного подраздления пилить кусочек для другого.

ну и чем больше задача - тем больше вероятность что в ТЗ что-то будет непокрыто.

и тем больше риски при планировании на основе ТЗ

проблема в том, что ты описываешь риски

причем риски исполнителя

а у заказчика все очень просто - никто не даст 5 лямов под неопределенных результат "ну мы чота сделаем"

причем риски исполнителя

ну я понимаю риски заказчика. Мы даем им деньги и у нас нет никаких гарантий что мы получим то что хотим

сколько там статистика по индустрии факапов таких? когда в фиксированный бюджет укладываются 20%-30% проектов

а у заказчика все очень просто - никто не даст 5 лямов под неопределенных результат "ну мы чота сделаем"

тут проблема не с тем что "мы чота сделаем" а в том что что бы понять что делать надо тоже времени потратить нехило

и ты выбираешь сделать продукт за N денег или тот же проект за 1,5N денег но зато с ТЗ

тут даже не в этом дело... а в том, что у заказчика нет того, кто принимал бы на себя риски. Есть отдел, который хочет сайт, есть бюджет отдела на год, есть согласующие отделы... нет того, кто скажет "да, мы понимаем, что у нас тут треш, по-этому давайте делать и мы вам по часам платить будем, а там 1 лям или 5 выйдет... ну не важно"

но для заказчика это выглядит как есть гарантии (хотя их нет, будто бы ты не знаешь как работает когда осознаешь что профакапились с оценкой)) и нет гарантий. То есть все это только про ложное чувство безопасности

тут даже не в этом дело... а в том, что у заказчика нет того, кто принимал бы на себя риски. Есть отдел, который хочет сайт, есть бюджет отдела на год, есть согласующие отделы... нет того, кто скажет "да, мы понимаем, что у нас тут треш, по-этому давайте делать и мы вам по часам платить будем, а там 1 лям или 5 выйдет... ну не важно"

а что если закладывать в ТЗ решение проблем а не фичи?) больше покрытие problem space оценивать и метрики эффективности решения вводить

что бы цели ставить а не стори

короч все это сложно.... а я просто не люблю писать/читать спецификации больше чем на 20 страниц

ну как-то дак и делается.. по сути сполнитель прикрывает себя, типа "Ну проблема решена - решена, а то, что для этого нужно сделать 5 приседаний и оборот вокруг носа... ну сами виноваты, бабла мало" ;)

мне больше подходят поведенческие сценарии + мокапы/прототипы

типа вместо того что бы подписывать контракт на десяток тысяч часов можно договориться на контакт на пару сотен часов и запилить пачку прототипов. И уже потом на основе фидбэка можно было бы более точно оценивать и развивать

p.s. с проектами больше чем а 5 человеколет по эстимейтам я не сталкивался

т.е. есть два варината - или ТЗ как можно более общее или ТЗ как можно более подробное. Но так как второй вариант долгий и дорогой, ясное дело, что работают все по прервому. Но тут есть вероятность, что придет юр отдел и закупочный отдел скажет, что "нужно поподробнее"

т.е. есть два варината - или ТЗ как можно более общее или ТЗ как можно более подробное. Но так как второй вариант долгий и дорогой, ясное дело, что работают все по прервому. Но тут есть вероятность, что придет юр отдел и закупочный отдел скажет, что "нужно поподробнее"

с общими ТЗ еще есть риски для исполнителя. В суде сложно доказать что то что реализовано совпадает с ТЗ, ровно так же как можно доказать что мы не выполнили требования (хотя вроде бы все ок))

типа вместо того что бы подписывать контракт на десяток тысяч часов можно договориться на контакт на пару сотен часов и запилить пачку прототипов. И уже потом на основе фидбэка можно было бы более точно оценивать и развивать

это идеальный вариант, когда результат нужен тому, кто кладет вырочку бизнеса в карман когда бизнес огромен - у каждого отдела есть свои потребности, но они не могут потратить часть бюджета и получить "какие-то картинки"

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

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

ну потому что не работает это в разработке. В строительстве у тебя чисто инженерная задача. Например крымский мост))

ну то есть.... это ж мост... у тебя задача не зависит от интерпритации факторов)

он тоже когда-то был в стадии "ну нам бы тут проехать между берегами"

ну вряд ли у архитекторов была возможность "я тут узнал про новый крутой материал, а давайте из него мост построим"

архитекторы - это как раз те, кто пишет ТЗ, если что ;)

или "мы подумали и решили, что хотим видеть рыбок, когда по мосту едем"

архитекторы - это как раз те, кто пишет ТЗ, если что ;)

ну им тоже кто-то пишет ТЗ

им дают задачу "нам бы проехать" и требования "не менее 100 машин в час... ну и про рыбок могут

про материал тоже могут дать вводные

архитекторы ближе к сеньерам/архитектам. а стоители - тупо кодеры

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

ну вряд ли у архитекторов была возможность "я тут узнал про новый крутой материал, а давайте из него мост построим"

погугли историю изменения бюджета на мост

ну бюджет явно менялся не потому что инженерам захотелось применить что-то необыное

ну бюджет явно менялся не потому что инженерам захотелось применить что-то необыное

и не потому что вскрылись какие-то детали по ходу работ которые никто не учитывал до)

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

да и проеб по бюджету там даст фору любому IT проекту

ошибки проектирования есть всегда, да... а теперь представь, если бы ТЗ было "ну нам бы тут мостик, что бы ездить"

ошибки проектирования есть всегда, да... а теперь представь, если бы ТЗ было "ну нам бы тут мостик, что бы ездить"

ну за 3.5 лярда баксов че-нить сварганим да

самый дорогой мост в мире

Скажите, встала необходимость генерировать события при переходе сущности в разные статусы. Кто ответственен за генерацию события?

ну так инженерия в отличии от разработки ПО - давно уже ремесло без особых возможностей маневра

Скажите, встала необходимость генерировать события при переходе сущности в разные статусы. Кто ответственен за генерацию события?

сущость

гугли доменные ивенты

ну так инженерия в отличии от разработки ПО - давно уже ремесло без особых возможностей маневра

ох.... сча

Тогда в сущность нужно передавать диспетчер событий получается?

блин не найду видос где чел вот эти стереотипы развенчивает

Тогда в сущность нужно передавать диспетчер событий получается?

нет, повторю, гугли про domain events

Ок, спасибо

блин не найду видос где чел вот эти стереотипы развенчивает

а ты своими словами...

Ок, спасибо

расскажи и мне, плиз, как нагуглишь. Тож интересно.

согласен, в строительстве иногда тоже есть место творчеству (взять туже саграду де фамилия в барселоне - масса инженерных находок). Но подавляющее большинство проектов - типовые, чистое ремесло. В реальном мире ты шибко против законов физики не попрешь. Разработка ПО же накладывает гораздо меньше ограничений, поэтому вариантов достичь цели гораздо больше

а ты своими словами...

работать надо. Но по факту основное различие между строительством и разработкой софта это лишь в различии стоимости фаз проектирования и построения. У нас построение это работа компилятора. Что позволяет модифицировать дизайн чаще. А в остальном все примерно одинаково. А главный момент что проеб по бюджету в строительстве встречается довольно часто. И там примерно те же проблемы, просто никто не берет в расчет тот факт что подавляющее количество строительства типовое. То есть все уже просто и понятно и много раз делали. А проекты которые прям крутые - там вечно приходится бюджет увеличивать.

то есть это не потому что разработчики более творческие, а потому что чаще нетиповые проекты

ну я тоже самое и написал

расскажи и мне, плиз, как нагуглишь. Тож интересно.

а самому погуглить?)

ну я тоже самое и написал

да, я не успел прочитать)

самый дорогой мост в мире

ну дык подстать самому дорогому стадиону в этой галактике) чё мелочиться на мост-то)

а самому погуглить?)

Мне больше интересно про отсутствие диспатчера

Сущность отдаёт эвенты, которые затем кто-то как-то диспатчит

хммм. В плане метод прям возвращает какой-то объект ивента?

Коллекцию тех, что были применены

Гугли)

Ход мысли уже подсказали)

Спасибо

А есть какие-то ресурсы по DDD, но человеческим языком, чтоб не хотелось умереть от скуки на первом абзаце

Вряд ли

Эванса можешь почитать) но судя под запросу тож мимо. Они все скучные. Не ток по ддд,а в целом за технику)

это печально)

А есть какие-то ресурсы по DDD, но человеческим языком, чтоб не хотелось умереть от скуки на первом абзаце

нет, DDD это про скуку. Конец истории

если ты не можешь осилить Эванса или там Вернона даже, то даже не стоит пытаться общаться на тему предметной области с экспертами в оной. ТОчно со скуки умрешь

если ты не можешь осилить Эванса или там Вернона даже, то даже не стоит пытаться общаться на тему предметной области с экспертами в оной. ТОчно со скуки умрешь

вот и ладушки

Странная позиция для того, кто считает себя программистом)

Попробуй посмотреть мой доклад про DDD. Вроде старался простым языком и быстро

https://youtu.be/7HXIrEsmlzM

Попробуй посмотреть мой доклад про DDD. Вроде старался простым языком и быстро

Спасибо, попробую

Попробуй посмотреть мой доклад про DDD. Вроде старался простым языком и быстро

я не помню, объяснял ли ты что DDD это в последнюю очередь про код или нет.... что мол смотря на код DDD не понять

а то люди часто путают это....

http://cqrs.nu/Faq

о тож занятная подборка терминов

я не помню, объяснял ли ты что DDD это в последнюю очередь про код или нет.... что мол смотря на код DDD не понять

Да, я рассказал, что ДДД это про общение с бизнесом, вытягивание информации, ее упорядочивание, и как следствие – представление домена в объектном виде. Плюс о том, что есть Data-Driven дизайн, когда идёшь писать код от структуры базы (обычно получается AR), а есть Domain-Driven. Ну и о том, что гонка за каноничным ДДД часто не имеет смысла и можно на AR спокойно пользоваться многими идеями из ДДД

Ради общего развития: а чтт такое каноничный ддд?

Ради общего развития: а чтт такое каноничный ддд?

Речь о коде. Каноничным называю ДДД с педантичным и фанатичным соблюдением писаний Эванса любой ценой

Речь о коде. Каноничным называю ДДД с педантичным и фанатичным соблюдением писаний Эванса любой ценой

Мерси

Речь о коде. Каноничным называю ДДД с педантичным и фанатичным соблюдением писаний Эванса любой ценой

Ну то есть бездумное следование "законам"?

да

https://youtu.be/7HXIrEsmlzM

Прекрасный доклад, только что на одном дыхании глянул ? Спасибо!

https://youtu.be/7HXIrEsmlzM

Спасибо огромнейшее, это именно то, что я искал! Распространю видосик по друзьям. Сергей говорит, что ддд - это в первую очередь про общение с бизнесом, но это и так понятно. А вот примеров реализаций с человеческими пояснениями не сыскать.

возвращаясь к событиям - я правильно понял, что события могут собираться только из агрегатов?

теперь осталось найти человекопонятную инфу об агрегатах и о том как их распознать)

Спасибо за отзывы :)

возвращаясь к событиям - я правильно понял, что события могут собираться только из агрегатов?

Не всегда. Иногда агрегаты работают с сущностями (Entities), которые могут порождать события. Я в таких случах писал в агрегате releaseEvents(), который также доставал события из сущностей, который принадлежат данному агрегату

Спасибо, буду щупать)

теперь осталось найти человекопонятную инфу об агрегатах и о том как их распознать)

Обычно агрегатом становится то, на что бизнес хочет/должен ссылаться из других сущностей и потому требует глобальной уникальности. Например, на строку счёта ссылаться обычно смысла нет, а на счёт целиком – можно

Но тут тема возвращается к общению с бизнесом. Если вы спросите "а вам нужно ссылаться на строку счёта", то вам скажут "конечно, нам нужно всё". Бизнесу вообще хорошо, когда всё может ссылаться на всё связями многие-ко-многим ?