design-data-modellisted

# design-data-model（業務の永続化を論理設計する） 読み終えると、対応する業務知識と検査済みの永続化シナリオから、何を記録しないと業務が回らないかを先に決め、BDDシナリオを含むRDB論理設計の本文を作れる。保存の形から入らない。イミュータブルデータモデルは業務知識を分析した結果として選ぶ候補であり、業務イベントという語があるだけでは採用しない。記録の必要を説明できない要素は、手法が何であれ要らない。物理設計、移行手順、性能はこのskillの外である。 ## 入力 | 入力 | 内容 | 満たさないときの扱い | |---|---|---| | 対応する業務知識 | 設計対象ごとに対応が分かる読み取り専用の業務知識資料。業務上の対象、状態、出来事、判断、取消・訂正を読む根拠 | 無ければ設計しない。テーブル、API、画面、既存DDLだけでは代替しない | | 検査済みの永続化シナリオ | 3操作の検討状況と条件マトリクスの検査を通ったもの。確からしさ（`confirmed` / `assumed` / `unknown`）を保っている | 無ければ設計を始めず、何が要るかを返す。`assumed` / `unknown`のシナリオは仮説として写す | | 手法（`modeling_method`） | 同梱の`fact-recording` / `normalized` / `dimensional`のID、または利用者の手法fileの絶対path。IDは`references/methods/<ID>.md`（[事実の記録](references/methods/fact-recording.md)、[正規化](references/methods/normalized.md)、[次元モデル](references/methods/dimensional.md)）に対応する | 依頼指定→文脈推定→利用者確認→仮説の順で決め、決め方を報告する。指したfileが無ければ止まる。先頭の候補だけを試さない | | 既存の論理設計資料 | 更新の場合だけ | 新規なら無くてよい | ## 判断基準 [記録すべき事実のシナリオ](references/fact-recording-contract.md)、[Event Sourcing](references/event-sourcing.md)、[データモデル](references/data-models.md)、[不変データモデリング](references/immutable-data-modeling.md)、[NULL回避](references/null-avoidance.md)、[関係データモデリングの原則](references/relational-data-modeling-principles.md)と、同梱の内部skill `write-bdd`の規律のうち業務イベント、概念の関係、BDDの前提・トリガー・失敗理由を読んでから始める。手法fileは選んだ1つだけを読む。利用者の手法fileは、同梱の3本と同じ節（先に決めること／成果物として出すもの／向くとき／向かないとき／見直しの問い）を持つことを確かめてから使う。 | 観察対象 | 述語 | 行動 | |---|---|---| | 記録候補の要素 | 記録が無かったとき、誰が何をできなくなるかを言える | 残す。「〜のため」で終わる説明しか無ければ外すか説明を足す | | 成立済みの事実と現