ну до каких пор можно добавлять фичи? со временем столько страничек, кнопочек, менюшек будет, и страниц в документации, что ни один человек не сможет разобраться. смысл в такой системе в чем?

И это правильно

Так не пилить же всё на один экран

Рост же не обязательно в плоскости формочек

в общем в огромных системах 80% функционала вообще не используется

Возьмите условный facebook и посмотрите на количество фич. Под фичами я имею ввиду в том числе Workplace. Постоянно что-то да будет

если процесс развития представляет из себя "выпили - запили" - то норм. если только "запили" - то со временем получится неподдерживаемая система (надо же, чтобы все работало)

хз, я фейсбуком не пользуюсь, заглядывал в него - чото какой-то он не оч... сейчас телега онли

И что? Если вам за эти 80%  фича-реквестов отвалили нормально денег в своё время, то в чём проблема?

работать по принципу "лишь бы было чем заняться" - ну да, норм подход

зрелый, так скажем)

Нет. Это принцип - делаем за то что платят

Добрый день.
Подскажите определение - aggregate store.

Можно ли так назвать базу, где хранятся агрегаты?

Можно ли сказать, что это репозиторий в коде?

Это именно место где ты хранишь стэйт. То есть обычно когда рассуждают о "идеальном сторе для агрегатов" выбирают между postgresql (потому что можно просто на все агрегаты всех aggregate type запилить табличку вида id + data в json + партицирование настроить по id агрегата) например и mongodb каким (я не говорю сча что они идеальны, это просто пример).

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

Спасибо!

Тут есть кто проводил big picture event storming воркшопы? Желательно еще с минимальным опытом попыток проведения оных ремоут (знаю что обычно это не работает)

Интересует опыт. В частности какие проблемы возникали, с чем приходилось больше бороться. И в целом последовательность действий.

Мол стоит ли делать между итерациями небольшие паузы что бы "все вместе" проходить все воркфлоу? Опасение что времени на все не хватит (возможно беспочвенное, по сути пройтись по флоу не так долго и в целом вместо обсуждения проблемы на 10 минут можно просто хотспот повесить и в крадце обозначить заинтересованных людей). Или же больше ставку делать на то что бы этот процесс распаралелить? Но тогда не все смогут послушать.

А то мне тут надо проводить и я хз как)

Сразу скажу - лишь пару раз проводил и оба ремоут.

До встречи сделал часовую сессию про ивент сторминг c практикой в конце,
так что многие участники были с ним знакомы.

Проблемы:
- многие стейкхолдеры просто не пришли, тк не понял фишки
- многие пришедшие просто пассивили, что было б менее вероятно оффлайн
- разрабы фокусируются на имплементации, а не бизнес ивентах
- многие сразу не понимают как сформулировать ивент
- куча событий может произойти в любой момент времени и их надо убирать с timeline
- нереально и участвовать и модерировать одновременно (но это с большинством митингов так)
- при подготовке читал книгу Альберто - зря. там одна вода и эмоции
- собраться все готовы были лишь на 2 часа и это конечно мало
- по флоу пройтись всё проговаривая заняло минут 20
- в первую сессию собрали events, hotspots, external systems, actors, pivotal events

Ценно, спасибо. Я для параллельных дискуссий на борде разметил по цветам 3 области и отдельные румы где можно уединиться обсудить. Хз будет ли толк

@m_regush, please, press the button below within the time amount specified, otherwise you will be kicked. Thank you! (60 sec)
Powered by Todorant

@VictorovMS, please, press the button below within the time amount specified, otherwise you will be kicked. Thank you! (60 sec)
Powered by Todorant