要検討confidence: highstatus: current
仕事の言葉とコードの名前がずれていないか
同じ概念が会話、画面、仕様、コードで別の名前になっている場合、理解のずれや変換漏れを疑います。
気になる兆候
- ・同じ概念に複数の名前がある
- ・汎用的な `data`、`item`、`process` が重要な業務概念を隠している
- ・画面の用語とAPI・コードの用語が一致しない
確認する質問
- ・この名前は仕事に詳しい人との会話でも使いますか？
- ・別名になっている理由は、境界の違いですか、それとも単なる表記揺れですか？
改善の候補
- ・具体的な業務例を一つ挙げて、その場面で使う言葉へ合わせる
- ・意味が異なるなら無理に統一せず、境界と変換を明示する
理由: ユビキタス言語は、チームの会話とモデルとコードをつなぐために使います。名前のずれは、モデルのずれを見つける手がかりになります。
重要confidence: highstatus: current
別の文脈のモデルがそのまま入り込んでいないか
同じ名前のモデルを複数の用途で共有し、関係のない属性や条件が増えている場合、Bounded Contextの境界を確認します。
気になる兆候
- ・一つの型に用途別のoptional項目が増え続ける
- ・変更理由の異なる機能が同じモデルを直接変更する
- ・外部システムのデータ構造が内部モデルへそのまま露出する
確認する質問
- ・このモデルの言葉とルールが一貫して通用する範囲はどこですか？
- ・境界を越える時に翻訳すべき概念はありませんか？
改善の候補
- ・用途ごとのモデルを分け、境界で明示的に変換する
- ・まずチームと言葉の境界を確認し、サービス分割はその後に判断する
理由: 同じ言葉でも文脈が変われば必要な意味やルールが変わります。一つの巨大なモデルへ統合すると、文脈ごとの一貫性が失われます。
要検討confidence: mediumstatus: experimental
一つの業務ルールが複数箇所へ散らばっていないか
同じ判断条件が画面、API、バッチなどに複製されている場合、そのルールを表すモデル上の場所を確認します。
気になる兆候
- ・似たif文が複数の入口にある
- ・業務上の可否をControllerやUIだけで判断している
- ・同じ変更で離れた複数箇所を必ず直す
確認する質問
- ・この判断には仕事上どんな名前がありますか？
- ・ルールを一つのモデル上の振る舞いとして表現できますか？
改善の候補
- ・ルールへ業務上の名前を付け、モデル側に集約する
- ・技術的な入力検証と業務ルールを区別する
理由: 重要な業務ルールが技術的な処理へ分散すると、変更時に一貫性を保ちにくくなります。