変わらないものが、変わるものを決める — 意図駆動開発 × イベントソーシング × イミュータブル | What Doesn't Change Decides What Can — IDD × Event Sourcing × Immutability

大吉祥寺.pm 2026 登壇資料「変わらないものが、変わるものを決める — 意図駆動開発 × イベントソーシング × イミュータブル」(2026-07-25)

リファクタリングでも仕様変更でも、私たちはいつも「何を変えないか」を先に決めています。不変の核を深く置くほど、変わるものは小さな力で動かせる — この登壇では、「イミュータブル(不変)+ 追記のみ」という一つの原理が、3つの層で同じ形で現れることを話します。

データ: 上書きから追記へ(イベントソーシング) — 「会計士は消しゴムを使わない」。出来事を追記し、状態は畳んで導く。SSoT(真実の源)はイベントの蓄積。4年以上の実践(Sekiban / SekibanWasmRuntime / SekibanCloud)と最新の DCB にも触れます
仕様、そして意図へ(意図駆動開発 / intent-cli) — プロンプトと意図を捨てて成果物だけ版管理していないか(Sean Grove「The New Code」)。意図をツリーにしてGitに残し、生成したタスク(packet)も履歴として積み、振り返って意図を強化する — 開発プロセスのイミュータブル化
イミュータブルに統一 = 変更は「追加」に揃う — コード(関数型)・データ(ES)・意図(IDD)の3層が「イミュータブル」で一つにまとまり、Open/Closed Principle(開放閉鎖の原則)と同じ設計姿勢に。ESの構造がAIコーディングでも有利に働く理由(意味的局所性・実行可能な遷移・観測面の強制・再生可能な入力)も紹介
AI時代の協働 — ハーネスで縛るのでなく、地図とコンパス(意図)を渡す。保存した意図が orchestrator の次の判断を決める
締めは吉祥寺.pmの慣習で一句 —「消さぬログ 明日の自分の 道しるべ」。

あなたのコードベースで「ずっと変わらないもの」は何ですか? それを Single Source of Truth に据えると、変更は怖くなくなります。

関連リンク: sekiban.dev / intent-driven-development.com / jtechs.com

English Abstract
Talk at Kichijoji.pm 2026 (Jul 25, 2026, Tokyo) — "What Doesn't Change Decides What Can".

In every refactoring or spec change, we always decide first what must NOT change. The deeper you place the invariant core, the easier everything else moves. This talk shows one principle — immutable + append-only — appearing in the same shape across three layers:

Data: from overwrite to append (Event Sourcing) — "Accountants don't use erasers." Append events, fold them into state; the source of truth is the accumulation of events. Four+ years of practice with Sekiban / SekibanWasmRuntime / SekibanCloud, with a nod to Dynamic Consistency Boundary (DCB)
From specs to intent (Intent-Driven Development / intent-cli) — Throwing away prompts and version-controlling only the output is "like shredding your source code and version-controlling the binary" (Sean Grove, "The New Code"). Keep intent as a Git-managed tree, stack generated task packets as history, and review them to strengthen intent — making the development process itself immutable
Unify on immutability = changes become additions — functional code, event-sourced data, and recorded intent all align with the Open/Closed Principle. Why this structure also helps AI coding: semantic locality, executable transitions, enforced observability, replayable inputs
Working with AI — hand over a map and compass (intent), not a harness; saved intent drives the orchestrator's next decision
Closing with a haiku, as is Kichijoji.pm tradition: "Logs never erased — a guidepost for the self of tomorrow."

What never changes in your codebase? Make it your single source of truth, and change stops being scary.

Links: sekiban.dev / intent-driven-development.com / jtechs.com

Transcript

1. 吉祥寺 変わらないものが、 変わるものを決める .pm 2026 意図駆動開発 イベントソーシング イミュータブル × × 丘 知央 株式会社ジェイテックジャパン 年 吉祥寺 きゅりあんイベントホール CTO / @tomohisa 7 25 ( ) .pm / 大 土 日 月 高 大 2026 スクショ OK SNS OK #kichijojipm
2. 丘 知央 紹介 - Tomohisa Takaoka X: @tomohisa GitHub: @tomohisa 株式会社ジェイテックジャパン、 グループ 中 企業の受託開発をモダンな開発スタイルで。イベントソー シング、 などのソフトウェアアーキテクチャに関するコンサル業 務。企業向けの 活 開発の 援 セミナー コンサルティングも展 開中 Works at: (JTS J-Tech Creations, Inc. ) CTO: CQRS AI Microsoft MVP for Developer Technologies from Nov 2024- / Microsoft On .NET Live 出演 OSS: Sekiban - Event Sourcing and CQRS Framework / intent-cli - 己 ・ ・ 支 用 小 高 自 Intent-Driven Development 2 / 38 スクショ OK SNS OK #kichijojipm
3. 本 のアジェンダ 背 変わらないものを先に決めると、変わるものがシンプルになる : 1. 2. 3. 4. 変わるもの 変わらないもの データ 上書きから、追記へ イベントソーシング 仕様、そして意図へ → イミュータブルに統 変更は「追加」だけ 時代の協働 地図とコンパス : ( ) (Spec-Driven Intent-Driven) = 5. AI : データ 仕様 協働 つの層で「上書き→追記」が同じ形で起きている 3 — ・ ・ 一 ・ 骨 日 AI 3 / 38 スクショ OK SNS OK #kichijojipm
4. 変わるもの 変わらないもの リファクタリングでも仕様変更でも、私たちはまず「何を変えないか」を決めています。不変の核を先に固 定すると、変えていい範囲がはっきりするýそしてデータ 仕様 協働の つの層で、いま同じ転換 上 書き→追記 が起きている。この主張を宣 する章です。 Chapter 1 AI 3 ( ・ 言 ・ ・ ) 4 / 38 スクショ OK SNS OK #kichijojipm
5. 私たちはいつも「何を変えないか」を先に決めている 1-1 変わるもの 変わらないもの リファクタリングでも仕様変更でも、まず「何は絶対に変えては いけないか」を決めているはず 変わらない核が決まると、変えていい範囲 由度 がはっきりする 問うべきは「どう変えるか」より先に「何が本当に不変か」 ( ) 自 ・ 不変を先に固定すると、変更はむしろ怖くなくなる 5 / 38 スクショ OK SNS OK #kichijojipm
6. 変わるもの 変わらないもの 不変の核を深く置くほど、変わるものを さな で動かせる 1-2 変わるもの さな を動かす強い い腕を押す 不変の核 点 ( = 書き ライブラリ 語 浅い 後から変えられる 影響は局所的 ( ) データ 意図の保存 式 アーキテクチャ 保存 式 意図 深い 取り戻せない 影響が根元に及ぶ ( ) ) 力 方 ・ 方 支 — 言 ・ 支 — 方 ・ 支 長 小 力 力 小 ・ 「その判断は、浅い 点か 深い 点か」を先に考える 6 / 38 スクショ OK SNS OK #kichijojipm
7. 変わるもの 変わらないもの 本トークの主張 重要な事実と判断を残すと、変更は「追加」と して扱いやすくなる 1-3 : データ 仕様 意図 AIとの協働 ↓ ↓ 状態を上書き コードだけ残す 出来事を追記 意図 ↓ イベントソーシング つの層で同じ形 → 意図を渡す 地図とコンパス ý 消して置き換える から 残して積み上げる へ Spec Intent-Driven 示 一 ・ ・ 3 を残す (why) 逐 の指 7 / 38 スクショ OK SNS OK #kichijojipm
8. データ 上書きから、追記へ イベントソーシング 状態を上書きすると「なぜ今こうなったか」が消えます。出来事を追記し、状態は畳んで導くのがイベント ソーシング。会計 は消しゴムを使わないý信頼が要る分野で昔から続く「消さない作法」と、得られる もの 引き受けるものを ていきます。 Chapter 2 見 ・ 士 : 8 / 38 スクショ OK SNS OK #kichijojipm
9. 上書きする世界では、「なぜ今こうなったか」が消える 2-1 データ 上書きから追記へ : 状態を上書きする は、今の値しか持たない 「昨 の状態」も「どういう順で なぜこうなったか」も復元できない 後から必要になる問い 監査 分析 不具合の追跡 に、データがもう答えられない DB ( ) ・ 力 ・ ・ 日 失われるのはデータではなく、後から問いに答える 9 / 38 スクショ OK SNS OK #kichijojipm
10. イベントソーシング 出来事を追記し、状態は畳んで導く 2-2 データ 上書きから追記へ : : append-only( 追記のみ ) 座開設 +0 ý 出来事は消さず、左から右へ積む +1,000 出 −300 +500 …追記 現在の残 畳み込み 状態は「結果」 出来事の列からいつでも再計算できる = 1,200( ) 真実の源 はイベントの蓄積。状態はそれを畳み込んだキャッシュにすぎない ) — 高 金 入 金 金 入 口 SSoT( 10 / 38 スクショ OK SNS OK #kichijojipm
11. 会計 は消しゴムを使わない 2-3 データ 上書きから追記へ : "All entries in a ledger remain in the ledger. Corrections can be made but only by making new entries." 「 記 を加えることによってのみ Pat Helland Immutability Changes Everything 」 (CACM 2016) — 元帳の記 はすべて残る。訂正はできるが、新しい 確定した仕訳は消さない。誤りは逆仕訳 訂正の を追記して打 ち消す だから「いつ 何を なぜ直したか」まで台帳に残る 信頼が要るからこそ、何千年も「消さない」作法が続いてきた ( ) — 行 ・ ・ 一 入 入 士 これはイベントソーシングそのもの 消さず、追記で直す 11 / 38 スクショ OK SNS OK #kichijojipm
12. データ 上書きから追記へ 「消さない記録」は、信頼や再現が要る所で繰り返し現れる 2-4 : 会計の元帳 訂正は逆仕訳を追記 銀 の取引台帳 明細を積み、残 は派 値として計算 のコミット 内容アドレスで新オブジェクトを積む 書換え不能ストレージ の監査ログ 既存を変えず、記録だ け追加 将棋 囲碁の棋譜 ずつ残せば盤 を再現できる Git (WORM) ※ どれも「絶対に書き換え不能」ではない。要点は元の記録を残し、変更履歴を積むという仕 組み。 生 高 — 飛 面 手 一 — ・ — — 行 — 追記型は突 なアイデアではなく、昔からある信頼の作法 12 / 38 スクショ OK SNS OK #kichijojipm
13. 消さないと何ができ、代わりに何を引き受けるか 得られるもの 2-5 データ 上書きから追記へ : 引き受けるもの 辿れる なぜ今こうなったかが残る 監 査証跡 時間旅 過去の任意時点の状態を復 元 後から新しい問い 出来事から新しい 集計 分析を せる リプレイ 再 して状態を再構築 検 証 保存量が増える スキーマ イベント の進化に設計が要る リプレイのコスト 削除要件 プライバシー への対応 「い つ なぜ消したか」も残す ( ) ( ( ) ) ・ 足 生 — ・ ・ — — — 行 — 「複雑性が下がる」ではなく、複雑さの置き場所を選ぶ設計判断 13 / 38 スクショ OK SNS OK #kichijojipm
14. 4 年以上の実践 Sekiban: Sekiban 誰でもイベントソーシング 、そして / CQRS 2-6 データ 上書きから追記へ : DCB を使えるようにする OSS フレームワーク 年以 (4 上 「 度書いたら消えない」から まれたプロダクト イベントは更新も削除もせず、追記だ けで積む 最新は タグで整合性境界を動的に決める 今 は深 追いしない ドメインコードを 化 など好きな 語でドメインを書ける 倒なバックエンドをマネージドで提供 リリース間近 。データは持ち出し てセルフホストへ移 可 ) Dynamic Consistency Boundary(DCB): ( ) SekibanWasmRuntime: Wasm SekibanCloud: ( — 日 — — 面 行 ) 「消さない設計」を、実プロダクトで回している 生 一 言 Rust / TypeScript / Swift / MoonBit 14 / 38 スクショ OK SNS OK #kichijojipm
15. 仕様、そして意図へ Chapter 3 ý Spec-Driven → Intent-Driven コーディングでも同じ転換が始まっています コードから仕様へ、そして仕様の背景にある「意図 」へ。プロンプトを捨てずに残す。決定を覆すときも消さず、「置き換え済み」の印を付けて積む 。意図をツリーにして に残す まで、「意図の追記」を辿ります。 AI (why) (ADR) Git intent-cli 15 / 38 スクショ OK SNS OK #kichijojipm
16. AIコーディングでも、同じ転換が始まっている 3-1 仕様、そして意図へ "We're moving from 'code is the source of truth' to 'intent is the source of truth.'" GitHub 「 」— 「コードが正本」から「意図が正本」へ Spec-Driven Development GitHub Spec Kit / Tessl: Driven Development) 安定した「何を 各フェーズが はなく 然 語の仕様を、版管理された第 級の成果物として保つ (Spec- 」と、柔軟な「どうやって 」を分ける 成果物を残し、 へ構造化された 脈を渡す 場当たりのプロンプトで (what) (how) Markdown ( 一 仕様を捨てず、版管理できる正本にする 文 言 自 ) AI 16 / 38 スクショ OK SNS OK #kichijojipm
17. 意図を捨てて、成果物だけ版管理していないか 3-2 仕様、そして意図へ 詰まるのは実装速度でなく、構造化された意図を共有する速度 その意図を、私たちはプロンプトとして に渡している なのに、 渡した後プロンプトを捨てている AI 成コードだけを に残すこの状況を、 Git Sean Grove はこう例えた : "This is like shredding your source code and then very carefully versioncontrolling the binary." 「 」— プロンプトと、そこにある意図を捨てる ことは ソースコードを裁断して、バイナリだけ 帳 に版管理するようなものだ Sean Grove(OpenAI) The New Code ( 面 几 生 — ) 17 / 38 スクショ OK SNS OK #kichijojipm
18. その先へ 仕様の背景にある「意図 (why) 」を残す 3-3 仕様、そして意図へ コードには は残る。だが なぜ作るか 何を判断したか は残らない だから を に残す 意図駆動開発 「何を作るか 仕様 」より、「なぜ 何を選んだか 意図 」が、後から きる不変の核 how / what why why( Single Source of Truth ) (IDD) = ( ) 仕様の 段上に、意図を置いて残す 生 一 ・ ・ — ( ) 18 / 38 スクショ OK SNS OK #kichijojipm
19. 古い決定は消さず、「置き換え済み」の印を付けて積む 3-4 ADR: 仕様、そして意図へ "If a decision is reversed, we will keep the old one around, but mark it as superseded." 「 」と印を付ける Michael Nygard 」— 決定を覆す時も古い記録を残し、「置き換え済み Documenting Architecture Decisions (superseded) なぜその決定をしたかを短く残す 番号は単調増加 再利 しない。古い決定は消さず「置き換え済み て、新しい決定を追加 これは意図の データと同じ形が、判断の記録にも現れる Architecture Decision Record = 」の印を付け (superseded) append-only 構造 用 — ・ : Title / Context / Decision / Status / Consequences 19 / 38 スクショ OK SNS OK #kichijojipm
20. intent-cli: 意図をツリーにして Git に残す 3-5 仕様、そして意図へ intent tree .intent MVV 理念 的 基本原則 守るべき前提 会話 (Intent Storming) 配下 / Git 判断理由 で整理し、 構造で管理 ・ packet の履歴 と 間が同じ前提を る AI も、消さず履歴として積む 方 見 人 — 木 どう作るか 過去のタスク 針 (packet) 目 生 技術選択 ADR 会話で決めたことも、 成したタスク ・ で差分管理 20 / 38 スクショ OK SNS OK #kichijojipm
21. orchestrator mode: 意図を渡して、開発を回す 間は「何を なぜ作るか」に集中し、進 管理は 1 2 orchestrator 3 4 状態確認 次に進める作業を判断 待ち 依存関係を把握 まりを検知して復旧 必要な に委譲 (intent-cli / GitHub) → 実装可能な単位に切り出す → やりたいこと 技術 針 制約 判断理由 未解決の質問 packet / / / GitHub issue (ADR) 仕様、そして意図へ が担う orchestrator thread 設計スレッド 3-6 CI receiver implementation receiver issue を読んで実装 ↓ PR 作成 PR / CI → を review receiver PR intent / packet ↓ と照合 approve closeout → 次の へ は履歴に 積まれる 依頼された時だけ 件ずつ処理 merge 間と が会話して を整理 意図と契約を持った 作業パケット AI intent 意図 間 針 判断 ⟲ 間判断が必要な場合だけ、設計スレッド へ戻す orchestrator 状態確認 委譲 進 管理 エージェント間はローカルの でメッセージング issue (packet ) loopless 1 receiver 実装 レビューの個別処理 ・ 行 ・ ・ ・ 方 ・ 人 — 人 人 方 止 ・ ・ 行 ・ 人 agmsg(SQLite) 21 / 38 スクショ OK SNS OK #kichijojipm
22. イミュータブルに統 Chapter 4 = 変更は「追加」に揃う データも意図も「残して積む」形にすると、変更は「追加」として揃えられます。これは と同じ、「既存の安定部分を壊さず、新しい要素を加える」設計姿勢。変更が破壊から加算へ変わ ると、履歴がレビュー 検証 巻き戻しの根拠になります。 Open/Closed ・ ・ 一 Principle 22 / 38 スクショ OK SNS OK #kichijojipm
23. イミュータブルに統 「イミュータブル」というキーワードで、3つの層がまとまる 4-1 コードのイミュータブル 関数型 メモリ内でも値を書き換えず、新しい値を作る。データ が変わらないから、並 処理でも安定して動く データのイミュータブル イベントソーシング 出来事を上書きせず追記する。履歴が確定 した事実として残る 意図のイミュータブル 意図駆動開発 意図と、 成したタスクの列 を追記で記録 する。間違えたとき振り返って、意図を強化できる イベントを残して後から分析するのと 同じ形 ( ) ( ( ) ) (packet) — 生 — — — 行 — 一 どの層も同じ形 主要な変更が「追加」に揃う 23 / 38 スクショ OK SNS OK #kichijojipm
24. これは Open/Closed Principle( イミュータブルに統 開放閉鎖の原則 と同じ姿勢 4-2 ) "Software entities should be open for extension, but closed for modi cation." 原型は 『 』 ており、修正に対して閉じているべきである 開放閉鎖の原則 Robert C. Martin(1996)/ Bertrand Meyer OOSC (1988, p.23) ( — ソフトウェアの構成要素は拡張に対して開い ) 要求が変わったら、動く古いコードを変えず、新しいコードを追加して振る舞いを広げる 鍵は抽象 固定した抽象に依存し、新しい派 を して拡張する ※ と は同じものではない 対象はコード構造 データ更新モデル 。共通するのは「既存の安定部分を壊さず、 新しい要素を加える」という設計姿勢。 append-only ( / ) 足 生 — fi 一 OCP 24 / 38 スクショ OK SNS OK #kichijojipm
25. イミュータブルに統 での実感 多くの機能追加を「追加」として局所化で 4-3 きる Sekiban 新しい問い を追加し、確定したイベント履歴から再計算できる 新しい振る舞い を追加し、変更範囲を局所化できる 過去イベントを上書きしない 下流が再利 できる確定した事実列が残る 新しい もリプレイで過去履歴から埋められる = read model = command handler read model Sekiban で経験した多くの変更が、「追加しやすい軸」に載っている ※ 新イベント型の追加は反対側の変更を む。 網羅的 で検出できるが、外部 の互換性は別途管理が必要。 closed union + match なら同 コードベース内の未対応箇所をコンパイラ 用 一 生 — — 一 consumer 25 / 38 スクショ OK SNS OK #kichijojipm
26. 変更が「破壊」から「加算」へ変わる イミュータブルに統 4-4 上書き 破壊的 = を 消す v1 v1 v2 ← 履歴を別に残さなければ戻せない 追記 加算的 追跡しやすい = v1 ( ) v1 + 差分 v1 + 差分 + 差分 履歴が残る ・ ・ 一 履歴が残るため、レビュー 検証 巻き戻しの根拠を持てる 26 / 38 スクショ OK SNS OK #kichijojipm
27. ES の構造が、 に「正解」を出しやすくする 4-5 イミュータブルに統 AI 意味的局所性 変更に必要な 脈が に局所化される。表 の の変更だけで済むことも多い 修正が 実 可能な遷移 過去イベント コマンド 新イベント が、そのまま へ 渡せる構造化された仕様になる 観測 の強制 全状態変化がイベント経由 振る舞いの差分が必ず える形で残る。上書き型 でも観測は作れるが、「含めずに作れてしまう」ためドリフトしやすい 再 可能な 過去バグの再現も、後付け も、リプレイで command / decider / projection projection Given( )- When( )- Then( ) AI = read model を使っている限り、この構造が強制される 正解の出やすいアーキテクチャに乗 れる 示 文 見 — — — — 力 入 生 面 行 — 一 ES 27 / 38 スクショ OK SNS OK #kichijojipm
28. 時代の協働 地図とコンパス Chapter 5 AI ý : との協働を、過去の会話だけに依存はできません。変わらない記録 意図 仕様 決定 が、次の 成を決め る ここでタイトルを回収します。縛るハーネスだけでなく、向かう先と現在地を す地図とコンパス 意図 を渡す協働のかたちへ。 AI ( ) (= 生 ・ 示 ・ ) 28 / 38 スクショ OK SNS OK #kichijojipm
29. AIとの協働を、過去の会話だけに依存できない 5-1 AI 時代の協働 セッションや担当エージェントが変わると、会話の 脈は けたり ドリフトしたりする だからこそ、変わらない記録 意図 仕様 決定 が、次の 成の前提になる 変わらないものが、変わるもの 次に 成されるコード を決める 残した意図が、AIの「次の ) 」を決める ・ 欠 (= 生 ・ ) 手 一 生 ・ 文 ý ( 29 / 38 スクショ OK SNS OK #kichijojipm
30. マイクロマネジメントではなく、意図を渡す 5-2 AI 時代の協働 逐 の指 マイクロマネジメント ではなく、 間に対するように 「どんな背景で どんな 標で作りたいか」 意図を渡す 縛るハーネス 安全帯 だけでなく、向かう先と現在地を す地図と コンパスを渡す 上位の意図を参照可能にしておけば、 は 分で道を選べる ( ) = ( ) AI 人 手 自 示 目 示 ・ 一 渡すのは 順ではなく、向かう先 30 / 38 スクショ OK SNS OK #kichijojipm
31. 保存した意図が、orchestratorの次の判断を決める 5-3 AI 時代の協働 設計スレッドが意図 背景 標 制約 を整理し、ツリーに残す 実装は、その意図に従って決定論的に回る は を"運転"せず、次の 順を案内す る 会話で決めたことがリポジトリに残るので、誰が いつ動いても同じ前提から始められる 実 した の履歴を振り返り、意図 を強化する イベント履歴を後 から分析するのと同じ形 ( ) (intent-cli AI ) packet ADR (improve) — ・ — ・ 行 ・ 手 ・ 目 ・ 意図もタスク履歴も追記 保存する 意図駆動は、開発プロセスのイミュータブル 化 31 / 38 スクショ OK SNS OK #kichijojipm
32. まとめ ずっと変わらないものを探す データ 仕様 協働ý つの層で「残す → 辿る → 活かす」という同じ形が 回くり返されました。最後 に問いを持ち帰ってください あなたのコードベースで「ずっと変わらないもの」は何か。それを Chapter 6 : AI 3 3 : に据えるところから始まります。 ・ ・ Source of Truth Single 32 / 38 スクショ OK SNS OK #kichijojipm
33. 3 つの層で、同じ転換が起きている 層 データ 仕様 意図 との協働 (why まとめ 追記 出来事を残して積む イベントソーシング 意図 決定 タスク履歴 を残す 意図を渡し、記録が次を決める (immutable / append-only) ( ) ) (packet) (IDD / ADR) ・ 貫く原理は つ 消さない。追記する。変更は「追加」だけ 示 ・ (mutable) — 一 一 ・ AI 上書き 状態を消して置き換える コードだけ残る は消える 逐 の指 で操作する 6-1 33 / 38 スクショ OK SNS OK #kichijojipm
34. 残す → 辿る → 活かす 残す 出来事 意図 決定を、消 さずに追記する 6-2 辿る 活かす まとめ → なぜ今こうなったかを、後 → 新しい問い 分析 の 成に活かす から辿れる AI 生 ・ ・ ・ ・ ・ ・ データ 仕様 AI協働で、この同じ形が3回くり返される 34 / 38 スクショ OK SNS OK #kichijojipm
35. 変わらないものが、変わるものを決める 6-3 まとめ あなたのコードベースで、 「ずっと変わらないもの」は何ですか? それを に据えると、 変更は「上書き」ではなく「追加」になる。 Single Source of Truth 自 消さない設計は、未来の 分とAIへの「辿れる地図」を残すこと 35 / 38 スクショ OK SNS OK #kichijojipm
36. 参考 献 リソース 6-4 Core references 「 「 Helland Fowler Event Sourcing 「 Rich Hickey / Datomic 『 Meyer 」 Immutability Changes Everything OOSC 』 The Value of Values (1988)/ R.C.Martin (1996) 「 「 (CACM 2016)/ 」 Sekiban(Event Sourcing / CQRS) intent-cli / Intent-Driven Development 」 sekiban.dev intent-driven-development.com 」 」 The New Code Documenting Architecture Decisions (ADR) ・ 文 Michael Nygard Tools & resources Open-Closed Principle 「 GitHub Spec Kit / Tessl / Sean Grove 」 まとめ 36 / 38 スクショ OK SNS OK #kichijojipm
37. 句 消さぬログ 明 あす の 分の 道しるべ ) 自 日 一 ( スクショ OK SNS OK #kichijojipm
38. Thank You 丘 知央 @tomohisa — 高 sekiban.dev · intent-driven-development.com · jtechs.com スクショ OK SNS OK #kichijojipm