My Architect, частка 8: Event Storming — кантроль паслядоўнасці, а не яшчэ адна дыяграма

Гэта восьмы артыкул серыі пра My Architect. Для тых, хто не чытаў папярэднія часткі, коратка: My Architect — сістэма, дзе праект жыве паміж сесіямі AI-агента. Адным бокам яна павернута да агента — ён вядзе праект праз MCP; іншым да чалавека — візуальны інтэрфейс паказвае, што агент ужо зрабіў, і ўвесь прагрэс па праекце. Гэты артыкул — пра адзін канкрэтны механізм такога кантролю.

Вітрына тут — Forklift, сярэдні дамен дастаўкі ежы з пяці bounded-кантэкстаў. Усе дошкі, лічбы аналізатара і фрагменты DSL ніжэй сапраўдныя: праект засідлены лакальна і праходзіць праз рэальны analyzeEsSequence. Нічога не выдумана.

Дыяграма дзеля дыяграмы бескарысная. Кантроль паслядоўнасці — не

У ўсіх нас ёсць гэтыя могілкі. Папка docs/architecture, дзе ляжаць прыгожыя PNG, намаляваныя паўгода таму, і ніводны ўжо не адпавядае коду. Дыяграма-карцінка — гэта здымак чыіхсьці добрых намераў на момант часу T. Яна нічога не правярае. Яна не ведае, што вы забыліся падключыць галінку адмены. Яна радасна пакажа стрэлку, якой у кодзе няма, і прамаўчыць пра пятнаццаць, якія ёсць.

Таму калі я кажу «агент малюе Event Storming дошку», у вас справядліва тузаецца вока. Яшчэ адна карцінка? Не. Розніца ў адным слове: паслядоўнасць.

Event Storming — гэта не дыяграма каробачак. Гэта раскладзеная ў часе гісторыя таго, як падзея спараджае рэакцыю, рэакцыя — каманду, каманда — новую падзею. У дамен­най падзеі («Заказ размешчаны») ёсць прычына. У каманды («Размясціць заказ») ёсць вынік. Палітыка («Як толькі плацёж аўтарызаваны → пацвердзіць заказ») — мост паміж чужой падзеяй і тваёй камандай. І вось гэтая ўласцівасць — усё мае прычыну і вынік — ператвараецца з прыгожай філасофіі ў машынна-правяральны інварыянт.

Калі падзея вісіць без прычыны — гэта пралом. Калі каманда не спараджае падзеі — пралом. Калі палітыка нічога не мосціць — пралом. Калі картка ізаляваная — нехта накідаў думку і не давёў. Гэтых праломаў не відаць вачыма на дошцы з сарака стыкераў. Але іх відаць аналізатару, які чытае граф паслядоўнасці.

Вітрына ў нас апетытная — Forklift: on-demand food delivery, from tap to doorstep. Пяць bounded-кантэкстаў: Ordering, Payments, Kitchen, Dispatch, Tracking. Роўна той клас дамену, дзе «забыўся падключыць галінку» каштуе рэальных грошай: ежа прыгатаваная — грошы не спісаныя; кур'ер не прызначаны — кліент скардзіцца.

Кантэкст Dispatch: каманды (сінія) → падзеі (аранжавыя), палітыкі-масты (бэзавыя), read-models (зялёныя), знешнія сістэмы (ружовыя), актары (жоўтыя) і адкрытыя пытанні — hotspot'ы (ромбы) унізе.

Чаму менавіта агенту гэта дае рычаг

Чалавек глядзіць на дошку і адчувае, што нечага не хапае. Часам знаходзіць. Часцей — не: увага не маштабуецца, на трыццатай картцы вы ўжо не памятаеце, ці звялі зыход каманды «Адхіліць заказ».

Агент не адчувае. Агент запускае дэтэрмінаваную праверку графа. analyzeEsSequence абыходзіць прычынна-выніковы граф дошкі і вяртае структураваны вердыкт: ok, спіс gaps з тыпам (isolated, event-without-cause, command-without-effect, policy-not-bridging) і ўзроўнем (warning / info), і асобна — openQuestions (hotspot-карткі).

Гэта і ёсць рычаг. У агента з'яўляецца пятля зваротнай сувязі, якая не хлусіць і не стамляецца:

1. Author — агент аўторыць дошку праз create_diagram(diagramType:'event-storming', nodeId), прывязваючы яе да вузла іерархіі (эпіку/ініцыятыве).
2. Validate — чытае праз get_diagram; поле sequence паказвае пралому ў гісторыі.
3. Refine — латае праз update_diagram і валідуе зноў, пакуль gaps не схлопнецца да нуля.
4. Re-validate during implementation — падчас рэалізацыі паўторна ганяе праверку: код разышоўся з гісторыяй → дошка зноў чырванее.

Агент не спрабуе быць разумным «на вока». Ён абапіраецца на танную дэтэрмінаваную праверку і ітэруе да зялёнага — роўна так, як ітэруе тэсты.

Пятля ў дзеянні: Ordering, ад чорнага чарнавіка да чыстай гісторыі

Спачатку агент накідаў v0 кантэксту Ordering — сумленны чарнавік, які накідвае жывы чалавек: схапіў асноўную нітку, паставіў пазнаку «сюды вернецца адказ з Payments» — і не давёў хвост.

event-storming
# фрагмент: показана только основная нить Ordering, на доске карточек больше

group "Ordering"
  [command] "Place order"
  [event]   "Order placed"
  [policy]  "Whenever Payment authorized → Confirm order"
  [command] "Confirm order"
  [event]   "Order confirmed"
  [command] "Cancel order"

connect "Place order" -> "Order placed"
# "Whenever Payment authorized → Confirm order" — ни к чему не подключена  (isolated policy)
# "Cancel order" — ни входящего, ни исходящего                            (isolated command)
# "Order confirmed" — без входящей причины                                (event-without-cause, info)

Агент чытае get_diagram, праганяе аналізатар і атрымлівае па v0:

27 cards · 19 connections · 1 contexts — 2 sequence gap(s), 0 open question(s)
gaps:
  • "Whenever Payment authorized → Confirm order" (policy) is not connected to anything
  • "Cancel order" (command) is not connected to anything

Два пралому-warning (ізаляваная палітыка вяртання з Payments і недазамкнуты хвост адмены) плюс адна info-пазнака («Order confirmed» без прычыны — спараджальная каманда не зведзена). Далей — refine: агент падключае спараджальную каманду, мосціць палітыку ў каманду пацвярджэння, замыкае хвост адмены выніковай падзеяй. Паўторная валідацыя v1:

34 cards · 30 connections · 1 contexts — 0 sequence gap(s), 3 open question(s)

Пралому схлопнуліся. Але — і гэта важна — дошка не стала пустой і не стала хлусіць «усё вырашана». Засталося роўна тры карткі, якія агент свядома пакінуў чырвонымі. Пра іх — ніжэй.

Тая ж пятля на Payments: дзе чарнавік асабліва небяспечны

Payments — кантэкст, дзе недаведзеная стрэлка азначае «ежа прыгатаваная, грошы не знятыя» або «грошы знятыя двойчы». Тут v0 быў дзіравым, і гэта нармальна: менавіта таму праверка і патрэбная.

Вердыкт аналізатара па v0 Payments:

25 cards · 15 connections · 1 contexts — 3 sequence gap(s), 0 open question(s)
gaps:
  • "Issue refund" (command) is not connected to anything        — путь возврата нарисован наполовину
  • "Chargeback opened" (event) is not connected to anything     — забытая ветка отказа
  • "On decline cancel order" (policy) missing outgoing command  — мост к отмене брошен на шве

Пасля refine агент замыкае шлях вяртання (Evaluate refund → Issue refund → Refund issued), зводзіць апрацоўку чарджбэка і дабудоўвае мост палітыкі decline у Cancel order. Вердыкт па v1:

39 cards · 27 connections · 1 contexts — 0 sequence gap(s), 3 open question(s)

І зноў — тры карткі застаюцца чырвонымі наўмысна (capture-vs-reject race, атрыбуцыя віны пры вяртанні, уладальнік liability па чарджбэку).

Астатнія тры кантэксты: той жа патэрн

Пятля ўсюды адна і тая ж. Што злавіў аналізатар у v0 — і да чаго схлопнулася ў v1:

Разам па праекце: 17 механічных праломаў злоўлена і закрыта, 15 адкрытых пытанняў свядома пакінута на віду. Ніводнай выдуманай лічбы — гэта вывад рэальнага analyzeEsSequence па засідленых дошках.

Што застаецца адкрытымі пытаннямі — і чаму гэта фіча, а не баг

Вось галоўная думка. Калі gaps схлопнуліся да нуля, у наіўнай сістэмы ўзнікла б спакуса сказаць «архітэктура гатовая». Гэта была б хлусня. Розніца паміж праломам і адкрытым пытаннем фундаментальная:

• Пралом — механічная недаведзенасць. Стрэлку забыліся правесці. Латаецца ў DSL за хвіліну. Не патрабуе рашэння — патрабуе акуратнасці. Менавіта гэта аналізатар абавязаны лавіць і патрабаваць латання.
• Адкрытае пытанне (hotspot) — нявырашанае бізнес-рашэнне. Яго нельга «залатаць» правядзеннем стрэлкі, бо яшчэ не выбрана, якую стрэлку праводзіць. Замаскіраваць яго «зялёным» — значыць моўчкі прыняць рашэнне за прадакт-оўнера. Горшае, што можа зрабіць архітэктура.

Таму hotspot'ы — першакласныя грамадзяне дошкі. Яны праходзяць валідацыю (ok=true), але застаюцца на віду як openQuestions. Дошка сумленна кажа: «механічна я звязная, але вось гэтыя развілкі чакаюць чалавека».

І самае прыгожае: адно бізнес-пытанне ўсплывае hotspot'ам з розных бакоў шва — адно і тое ж пытанне відаць з некалькіх кантэкстаў адразу. Гэта не дубляванне, а карта таго, каго закране рашэнне, калі прадакт яго нарэшце прыме:

• Даступнасць кур'ера (SLA). «Пасля N рэтраяў / T хвілін без кур'ера — прытрымаць гатоўку, падняць аплату кур'еру, або аўта-адмена + вяртанне?» Відаць у Dispatch (No courier available), Ordering (Hold or auto-cancel) і Payments (refund-галінка) адначасова.
• Гонка capture-vs-reject. «Калі адмова рэстарана прыйшла пасля спісання — гэта void холда ці ўжо RefundIssued?» Вісіць у Payments, Kitchen і Ordering. Адзін race condition, які ніхто пакуль не вырашыў — і дошка не дае пра яго забыцца.
• Атрыбуцыя віны пры вяртанні пасля гатоўкі (customer / courier / restaurant-fault) — hotspot у Payments, Dispatch і Tracking адразу, бо парог manual-review яшчэ не зададзены.
• Fallback натыфікацый (што рабіць, калі падае Push/SMS/Email-шлюз) і пратуханне ETA — сумленныя адкрытыя пытанні Tracking, якія аналізатар не маскіруе.

Зялёны аналізатар не азначае «рашэнні прынятыя». Ён азначае «гісторыя механічна звязная, і ўсе нявырашаныя развілкі яўна паднятыя на паверхню, а не ўтопленыя ў маўчанні». Гэта роўна тая мяжа, якую вы хочаце паміж тым, што агент мае права дабудаваць сам, і тым, дзе ён абавязаны паклікаць чалавека.

Артэфакт: гэта не карцінкі, гэта працуючы праект

Усё вышэй — не мокап у графічным рэдактары. Гэта засідлены праект, які адкрываецца ў прадукце:

• Forklift — ініцыятыва і 5 эпікаў (па адным на bounded-кантэкст), кожны эпік валодае сваёй Event Storming дошкай.
• 178 картак, 142 сувязі на пяці дошках; кожная дошка праходзіць analyzeEsSequence з нулём warning'аў і трыма openQuestions.
• Дошкі прывязаны да вузлоў іерархіі — значыць «v0 → v1» гэта не разовая чыстка, а жывы кантроль: калі код разыдзецца з гісторыяй, дошка зноў пачырванее.

Як паспрабаваць самому — ужо можна

Гэта не «калі-небудзь зарэлізім». Увесь тулчэйн абноўлены і даступны прама зараз:

• Прыкладанне — тып event-storming раскатаны на my-architect.app: дошкі рэндэрацца, раскладваюцца па прычынным графе (ELK), ствараюцца прама з іерархіі (вузел → «+» → Event Storming).
• MCP — @my-architect/mcp@1.6.1 апублікаваны ў npm: інструменты create_diagram(diagramType:'event-storming', nodeId), get_diagram (вяртае поле sequence з праломамі) і update_diagram (refine + пера-аналіз).
• Скіл — my-architect v1.11.0 у маркетплейсе: нясе правіла «для эпіка/ініцыятывы па змаўчанні право­дзь Event Storming суб-задачай і рэ-валідуй паслядоўнасць падчас рэалізацыі».

Усталёўка ў Claude Code:

1. Завядзі акаўнт на my-architect.app, вазьмі токен на старонцы API Keys і экспартуй яго ў той жа сесіі, дзе запускаеш Claude Code:

``bash export MCP_API_KEY=mcp_ВАШ_ТОКЕН ``

1. Дадай маркетплейс і пастаў плагін (MCP-сервер падключыцца сам — npx -y @my-architect/mcp@latest, MA_API_URL=https://my-architect.app):

`` /plugin marketplace add d7561985/my-architect-marketplace /plugin install my-architect@my-architect-marketplace ``

1. Дай агенту эпік або ініцыятыву і папрасі разлажыць Event Storming — ён сам пройдзе пятлю create_diagram → get_diagram (sequence) → update_diagram да зялёнага, пакінуўшы адкрытыя пытанні hotspot'амі.

Ужо стаіць плагін? Абнаві да свежых інструментаў і правіла: /plugin marketplace update my-architect-marketplace → /plugin update my-architect.

Вывад: практыка для каманд

Калі прыбраць увесь Forklift і пакінуць сутнасць — рабочы рэцэпт:

1. Перастаньце ставіцца да дыяграм як да карцінак. Бярыце фармат з правяральным інварыянтам. У Event Storming ён убудаваны: усё мае прычыну і вынік.
2. Зрабіце праверку паслядоўнасці таннай і дэтэрмінаванай. analyzeEsSequence паверх дошкі — гэта лінтэр для архітэктуры. Пралому (isolated, event-without-cause, command-without-effect, policy-not-bridging) — гэта памылкі кампіляцыі вашай гісторыі.
3. Дайце пятлю агенту, а не разовы прагон. create_diagram → get_diagram (validate) → update_diagram (refine) → re-validate падчас рэалізацыі. Агент ітэруе да зялёнага так жа, як да зялёных тэстаў — без стомленасці і без «быццам усё падключыў».
4. Жорстка раздзяляйце пралом і адкрытае пытанне. Пралом латае агент. Адкрытае пытанне трымаецца hotspot'ам на віду і чакае чалавека. Сістэма, якая маскіруе другое пад першае, моўчкі прымае бізнес-рашэнні за вас — горшы від тэхдоўгу.
5. Прывязвайце дошку да вузла іерархіі (эпіку/ініцыятыве), а не да паветра.

Самае каштоўнае тут нават не тое, што агент латае пралому. А тое, што ён дакладна ведае, дзе латаць нельга — і пакідае гэтыя месцы чырвонымі, падпісанымі і бачнымі. Архітэктура, якая сумленна кажа «вось гэтага я яшчэ не ведаю», каштуе даражэй за любую прыгожую дыяграму, якая робіць выгляд, што ведае ўсё.