技術文書で使う用語の標準表である。先に規則を書き、グループごとの表を置き、
最後に使わない言い換えの一覧と出典をまとめる。表は増やしていく。
規則
- 原語が英語の用語は英語のまま書く。 promotion gate、bake、expand / contract、
outbox。訳語を新しく作らない。カタカナ表記が定着しているもの（デプロイ、
カナリア、ロールバック、バックフィル）はカタカナでよい
- 定訳があればそれを使う。 fitness function は『進化的アーキテクチャ』の訳書に
従って適応度関数、observability は可観測性。定訳と原語の両方が通る場合は、
初出で「適応度関数（fitness function）」のように併記する
- 比喩を作らない。 「レバー」「被弾」「置く・当てる・見せる」のような言い換えは、
具体的な語（巻き戻しの手段、失敗したリクエスト、デプロイ・トラフィック切替・
リリース）で書く
- 文脈で語が変わるものは、どの文脈でどれを使うかを決める。 同じ「戻す」でも、
デプロイはロールバック、フラグは OFF に戻す、一般論は巻き戻し
- 固有の語は固有の語として書く。 ECS の
stopDeployment、Keycloak の
client_credentials のような API や設定の名前は、コード体で原文どおり
- 列挙や図の並びでは英語に統一する。 「promotion gate・カナリア・bake・ロールバック」のように
英語とカタカナが混ざると読みづらい。並べるときは「promotion gate・canary・bake・rollback」と
英語でそろえる。単独で本文に出るときはカタカナでよい
- 書いたら機械で確認する。 使わない言い換えの一覧を grep で当てる。
タイトルの長さ規約と同じく、人の記憶に頼らない
デリバリー
| 標準の語 | 原語 | 意味 | 文脈による使い分け | 使わない |
|---|
| デプロイ | deploy / deployment | 新しいバイナリを本番環境に配置する | 「デプロイする」。配置の完了と公開は別 | 置く、投入 |
| トラフィック切替 | traffic shifting | 実ユーザーのリクエストをどの版にどれだけ向けるか | 表記は「切替」に統一 | 当てる、振り分け |
| リリース | release | 機能をユーザーの目に触れさせる | フラグによる公開も含む | 見せる、公開（単独では使わない） |
| プログレッシブデリバリー | progressive delivery | デプロイ・トラフィック切替・リリースを分解し、段階的・可逆的にする考え方 | | 段階的デリバリー |
| Blue/Green、B/G | blue/green deployment | 新旧 2 系統を並走させ、向き先を一斉に掛け替える | 本文は Blue/Green、表や図は B/G | 青緑 |
| rolling update | rolling update | タスクを少しずつ入れ替える。旧版を温存しないので bake ができない | B/G との対比で使う | ローリング |
| recreate | recreate | 旧版を全部止めてから新版を起動する。停止を伴う | 対比でのみ | 再作成 |
| カナリア | canary | まず n% だけ新版に向けて観測する | 本文中の単独ではカナリア、英語の語と並ぶ列挙や図では canary | 試験投入 |
| A/B テスト | A/B testing | 複数の版を同時に出して効果を比べる。壊れていないかを見る canary とは目的が違う | 対比でのみ | |
| dark launch | dark launch | 新機能をユーザーに見せずに本番で動かす。feature flag で実現する | | ダークローンチ |
| promotion gate | promotion gate | 本番トラフィックを向ける前に、テスト経路で新版を検証する段 | ECS では deployment lifecycle hook（POST_TEST_TRAFFIC_SHIFT）で実装 | 昇格ゲート |
| bake | bake（bake time） | 全量切替の後も旧版を落とさず併走させる監視時間 | 「bake 2 分」 | 焼き込み、様子見 |
| ロールバック | rollback | デプロイを前の版に戻す | デプロイの文脈。ECS では stopDeployment。列挙では rollback | 巻き戻し（デプロイの文脈では） |
| roll forward | roll forward | 戻さずに修正版を前に出す。DB の contract 後など戻せないときの選択 | rollback との対比 | 前進修復 |
| 巻き戻し | — | デプロイ・トラフィック・フラグを問わず「戻す」一般 | 複数の手段をまとめて言うとき | 戻し |
| フィーチャーフラグ | feature flag / feature toggle | コードをデプロイしたまま機能の公開を制御する | OpenFeature に合わせて flag。Fowler の原語は toggle。列挙では feature flag | スイッチ、トグル |
| キルスイッチ | kill switch | 機能を即座に止めるためのフラグ | | 緊急停止フラグ |
| ops toggle、release toggle | ops toggle / release toggle | フラグの種類。運用で切るものと、段階公開のためのもの | Fowler の分類。寿命が違うので混ぜない | |
| ロールアウト | rollout | 新版や機能を段階的に広げること | release は「公開する」、rollout は「広げていく過程」 | 展開 |
| リリーストレイン | release train | 決まった時刻にまとめて出す方式 | 歴史の文脈 | リリース列車 |
| 無停止 | zero-downtime | 切替をまたいでも失敗したリクエストが無い | 「非 200 ゼロ」のように数字を添える | ノーダウンタイム |
| 失敗したリクエスト | failed requests | 壊れた版に流れて失敗したリクエストの数 | 「0 / 1,679」のように分母を添える | 被弾、犠牲 |
DB マイグレーション
| 標準の語 | 原語 | 意味 | 文脈による使い分け | 使わない |
|---|
| expand / contract | expand / contract（Parallel Change） | 互換を保って先に広げ、旧版が消えてから縮める | 「expand を適用」「contract は後続リリースで」 | 拡張 / 縮退 |
| バックフィル | backfill | 新カラムに過去分のデータを埋める | 「batch 50、pause 100ms」のように刻みを添える。列挙では backfill | 埋め戻し |
| dual write | dual write | 新旧両方に書く。expand の期間中の書き込み | 「書き込みは常に両方」 | 二重書き込み |
| マイグレーション | migration | スキーマを変える手順と、その適用 | データ移行（data migration）と区別する | |
| 無停止移行 | online migration | サービスを止めずにスキーマを変える | | オンラインマイグレーション（併記は可） |
| N-1 互換性 | N-1 compatibility | 新旧 1 世代差のバイナリが同時に正しく動く | トラフィック切替の前提として | 後方互換（API の文脈と混ざる） |
ALGORITHM=INSTANT | MySQL の DDL オプション | メタデータだけで終わる DDL | コード体で原文 | 即時 DDL |
| COPY | ALGORITHM=COPY | テーブル全体を作り直す DDL | 「COPY は 2M 行 56 秒」 | フルコピー |
| カラム改名 | column rename | expand → backfill → feature flag → contract で改名する | 「改名」で統一 | リネーム |
進化的アーキテクチャ
| 標準の語 | 原語 | 意味 | 文脈による使い分け | 使わない |
|---|
| 適応度関数 | fitness function | 守りたい性質が保たれているかを機械で判定する検査 | 定訳。初出で原語を併記 | フィットネス関数、健全性チェック |
| 漸進的変更 | incremental change | 小さく変えて小さく確かめる | 定訳 | インクリメンタルな変更 |
| アーキテクチャ量子 | architectural quantum | 独立して変えられる最小の単位 | 定訳 | クォンタム |
| fail open / fail closed | fail open / fail closed | 検査自体が壊れたとき、通す側に倒れるか止める側に倒れるか | 英語のまま | 開放故障、閉鎖故障 |
| fail fast | fail fast | 続行せず早く失敗させる。通らない DDL をエラーで返すなど | fail closed は検査の倒れ方、fail fast は処理の止め方 | |
| モジュラーモノリス | modular monolith | 1 つのデプロイ単位の中で境界を機械で守る構成 | 分散モノリスの対義ではない | |
| 腐敗防止層 | anti-corruption layer | 他システムのモデルを自分の境界で変換する層 | DDD の定訳 | ACL（アクセス制御と混ざる） |
| 境界 | boundary | モジュール・サービス・DB の分かれ目 | 「境界を機械で守る」 | バウンダリ |
| 分散モノリス | distributed monolith | 分かれているのに独立してデプロイできない状態 | | |
| 共有カーネル | shared kernel | 分割せず参照データとして共有する中核 | DDD の語 | 共通部品 |
可観測性
| 標準の語 | 原語 | 意味 | 文脈による使い分け | 使わない |
|---|
| 可観測性 | observability | 外から見える出力で内部の状態を推定できること | 定訳。「o11y」は会話のみ | 監視（monitoring とは別） |
| 三本柱 | three pillars | メトリクス・トレース・ログ | | |
| トレース、スパン | trace / span | 1 リクエストの経路と、その中の 1 区間 | trace_id / span_id はコード体 | 追跡 |
| 構造化ログ | structured logging | 1 行 1 JSON のログ | | JSON ログ |
| canonical log line | canonical log line | 1 リクエスト 1 行に詰めたアクセスログ | 英語のまま | 要約ログ |
| 相関 ID | correlation ID | ログとトレースを結ぶ鍵。W3C Trace Context の trace_id | | 追跡 ID |
| 昇格シグナル | — | 構成を見直すべきかの判断材料となるメトリクス（プール使用率・authz レイテンシ・outbox 滞留） | greenfield の固有語。初出で説明を添える | |
| エラーバジェット | error budget | SLO を満たしつつ許容できる失敗の量 | | 許容誤差 |
| SLI / SLO / SLA | — | 指標 / 目標 / 契約 | 3 つを混ぜない。SLA は契約の語 | |
| 監視 | monitoring | 既知の状態を閾値で見張る | 可観測性は未知の問いに答えられること。別の語 | モニタリング（併記は可） |
| ヘルスチェック | health check | 稼働を確認する問い合わせ | liveness（生きているか）/ readiness（受け付けられるか）/ startup（起動中か）を区別する | 死活監視 |
| グレースフルシャットダウン | graceful shutdown | 受け付けを止め、処理中を終えてから終了する | 「drain」は接続を抜く段階 | 排水、優雅な停止 |
| タイムアウト、デッドライン | timeout / deadline | 待つ上限 / 期限の時刻。デッドラインは下流へ残り時間として伝播する | | 時間切れ |
| リトライ、バックオフ | retry / backoff / jitter | 再試行と、その間隔の延ばし方とゆらぎ | 冪等な操作にだけ | 再送 |
| サーキットブレーカー | circuit breaker | 失敗が続く呼び先への呼び出しを一時的に遮断する | | 遮断器 |
認証・認可
| 標準の語 | 原語 | 意味 | 文脈による使い分け | 使わない |
|---|
| 認証 / 認可 | authentication / authorization | 誰かを決める / 何をしてよいかを決める | 必ず分けて書く | 認証認可（ひとまとめ） |
| OIDC | OpenID Connect | ログインのプロトコル | 発行元は issuer | |
| issuer | issuer | トークンの発行元 URL（iss） | 英語のまま | 発行者 |
| M2M | machine-to-machine | サービス間の認証。client_credentials | 「M2M トークン」 | サービス間認証（併記は可） |
| ステップアップ認証 | step-up authentication | 危険操作の前に追加の認証を求める | | 再認証（一般語と混ざる） |
| AAL | Authenticator Assurance Level | 認証の強度。NIST SP 800-63B | 「AAL2」 | 認証レベル |
| IAL / FAL | Identity / Federation Assurance Level | 身元確認の強度 / 連携の強度。NIST SP 800-63-3 | AAL と並ぶ 3 軸 | |
| RBAC / ABAC / ReBAC | role / attribute / relationship-based access control | 役割 / 属性 / 関係で判定する認可 | 3 つを区別する | |
| トークンイントロスペクション | token introspection | トークンの有効性を発行元に問い合わせる | JWT のローカル検証との対比 | |
| ReBAC | relationship-based access control | 関係タプルで判定する認可 | OpenFGA の文脈 | 関係ベース認可 |
| スコープ | scope | トークンに付く権限の範囲 | internal:* はコード体 | 権限（authorization と混ざる） |
構造とデータ連携
| 標準の語 | 原語 | 意味 | 文脈による使い分け | 使わない |
|---|
| モノレポ | monorepo | 複数のサービスを 1 つのリポジトリで持つ | | 単一リポジトリ |
| outbox / inbox | outbox / inbox pattern | 業務の書き込みと同じトランザクションでイベントを記録し、別経路で配送・受信する | 英語のまま | 送信箱、受信箱 |
| relay | relay | outbox の未送信をバスへ送る常駐処理 | 英語のまま | 中継 |
| at-least-once | at-least-once delivery | 重複はあるが欠落はない配送 | 英語のまま | 最低 1 回配送 |
| at-most-once | at-most-once delivery | 欠落はあるが重複はない配送 | 英語のまま | |
| exactly-once | exactly-once（processing） | 配送は at-least-once のまま、受信側の重複排除で処理を 1 回にする | 「exactly-once の配送」とは書かない。処理の性質として書く | 厳密 1 回 |
| 重複排除 | deduplication | 同じメッセージを 2 回処理しない | inbox や冪等キーで実現する | デデュープ（併記は可） |
| 順序保証 | ordering | 同じグループ内で送信順に届く | SNS / SQS FIFO の文脈 | |
| 強整合性 | strong consistency | 書き込み直後に全員が同じ値を読める | 結果整合性との対比 | |
| トランザクション境界 | transaction boundary | 1 つのトランザクションに含める範囲 | 「outbox への追記は同じトランザクション」 | |
| ストラングラー | strangler fig | 旧システムを少しずつ置き換える移行パターン | Fowler の語 | 絞め殺し |
| 冪等キー | idempotency key | 同じ操作の試行を同一と見なす鍵 | Idempotency-Key はコード体 | 重複防止キー |
| 結果整合性 | eventual consistency | 時間がたてば整合する | 定訳 | 最終的整合性 |
| 配送 | delivery（メッセージ） | バスがメッセージを届けること | SNS → SQS の文脈 | 配信（放送の語感） |
基礎理論の語
設計の語の下にある理論の語。原典の著者と年を添える。
情報理論と符号
| 標準の語 | 原語 | 出典（著者・年） | 意味 | この文書群での対応 |
|---|
| 情報量、ビット | information / bit | Claude Shannon, “A Mathematical Theory of Communication”（1948）。bit の語は John Tukey | 不確かさの減り方を測る単位 | |
| エントロピー | entropy | Shannon（1948） | 情報源の不確かさの平均 | 比喩として「コードのエントロピー」とは書かない。使うなら乱数の品質など本来の意味で |
| 冗長性 | redundancy | Shannon（1948） | 伝えたい量より多く送る分。誤りの検出と訂正に使う | 冗長構成（Multi-AZ）とは別の語。文脈で区別する |
| 信号と雑音、SN 比 | signal / noise、signal-to-noise ratio | 通信工学。Shannon–Hartley の定理（1948） | 本物の信号と、それを隠す揺れ | アラートの「ノイズ」、差分運用で「揺れる検査を飼う」はこの比喩。使うときは何が信号かを書く |
| 誤り検出、誤り訂正 | error detection / correction | Richard Hamming, “Error Detecting and Error Correcting Codes”（1950） | 受け取った側で壊れを見つける / 直す | チェックサム、CRC |
| チェックサム、CRC | checksum / cyclic redundancy check | CRC は W. Wesley Peterson（1961） | データの壊れを検出する短い値 | 転送や保存の検証 |
| ハッシュ、ダイジェスト | hash / digest | 暗号学的ハッシュは Merkle–Damgård 構成（1979）。SHA-2 は NIST FIPS 180-2（2001） | 任意長の入力から固定長の値を作る。暗号学的ハッシュは衝突を見つけにくい | イメージの digest、cosign の署名対象、秘密の比較はハッシュで |
| 圧縮（可逆 / 非可逆） | lossless / lossy compression | Huffman 符号（1952）、Lempel–Ziv（1977 / 1978） | 元に戻せる圧縮 / 戻せない圧縮 | ログの保管、画像 |
| 符号化 | encoding | — | 情報を別の表現にする（圧縮も暗号化も含む広い語） | base64 は符号化であって暗号化ではない。混同しない |
| 乱数、疑似乱数 | random / pseudorandom | — | 真の乱数 / 決定的に生成した乱数列 | trace_id、冪等キーには暗号学的に安全な乱数を使う |
データベース理論
| 標準の語 | 原語 | 出典（著者・年） | 意味 | この文書群での対応 |
|---|
| 関係モデル | relational model | Edgar F. Codd, “A Relational Model of Data for Large Shared Data Banks”（1970） | データを関係（表）で表し、関係代数で操作する | リレーショナルモデルと併記は可 |
| 関係代数 | relational algebra | Codd（1970） | 選択・射影・結合などの演算 | SQL の背後にある語 |
| SQL | Structured Query Language | Chamberlin & Boyce（1974）。ISO/IEC 9075 | 関係データベースの問い合わせ言語 | |
| 正規化、正規形 | normalization / normal forms | Codd（1971–74）。BCNF は Boyce & Codd（1974） | 更新時の矛盾を防ぐために関数従属に沿って表を分ける | 第 3 正規形、ボイス・コッド正規形 |
| 関数従属 | functional dependency | Codd（1971） | ある属性が決まれば別の属性が決まる | 正規化の判定基準 |
| 非正規化 | denormalization | — | 読みの速さのために意図的に冗長を持つ | readmodel、replicaview |
| 候補キー、主キー、外部キー | candidate / primary / foreign key | Codd（1970） | 行を一意に決める属性の組 / 選んだもの / 他の表の主キーへの参照 | 外部キーのグラフが habakiri の入力 |
| 参照整合性 | referential integrity | Codd（1970）。SQL の制約として SQL-89 | 外部キーの先が必ず存在する | DB をまたぐ外部キーを禁じる話。CASCADE はライフサイクル一体の印 |
| 結合 | join | Codd（1970） | 複数の表を条件で組み合わせる | 内部 / 外部 / 自己結合 |
| トランザクション、ACID | transaction / ACID | Gray（1981）、Haerder & Reuter（1983） | 古典の表と同じ | |
| 直列化可能性 | serializability | Eswaran, Gray, Lorie, Traiger（1976）。Papadimitriou（1979） | 並行実行の結果が、何らかの直列実行と同じになる | 分離レベルの最上位 |
| 分離レベル | isolation levels | ANSI SQL-92。批判は Berenson ほか, “A Critique of ANSI SQL Isolation Levels”（1995） | READ UNCOMMITTED / READ COMMITTED / REPEATABLE READ / SERIALIZABLE | 異常の語: ダーティリード、ノンリピータブルリード、ファントムリード |
| 2 相ロック | two-phase locking（2PL） | Eswaran ほか（1976） | ロックを取る段階と放す段階を分けて直列化可能性を保証する | 2 相コミット（2PC）とは別の語 |
| MVCC | multiversion concurrency control | David Reed（1978）。Bernstein & Goodman（1981） | 行の複数の版を持ち、読みがロックを待たない | InnoDB の読み。「読みがロック待ち行列に並ばない」 |
| スナップショット分離 | snapshot isolation | Berenson ほか（1995） | トランザクション開始時点の版を読む | |
| ロック待ち、デッドロック | lock wait / deadlock | — | 他のトランザクションのロックを待つ / 互いに待ち合う | MySQL の 1205 はロック待ちのタイムアウト、1213 がデッドロック。区別する |
| WAL | write-ahead logging | Gray（1978）。ARIES は Mohan ほか（1992） | 変更を先にログへ書き、障害後に復元する | 永続性の実装。レプリケーションもこれを使う |
| B ツリー、B+ ツリー | B-tree / B+ tree | Bayer & McCreight（1972） | ディスク向きの平衡木。RDB のインデックスの標準 | インデックスの追加は ALGORITHM=INPLACE |
| LSM ツリー | log-structured merge-tree | O’Neil, Cheng, Gawlick, O’Neil（1996） | 追記して後でまとめる。書き込み重視のストア | RDB との対比でのみ |
| インデックス | index | — | 検索を速くするための補助構造 | 索引と書かない |
| レプリケーション | replication | — | 同じデータを複数のノードに持つ | プライマリ / レプリカ。マスター / スレーブとは書かない |
| 読み取りレプリカ | read replica | — | 読みだけを受けるレプリカ | ReplicaView の語源 |
| パーティショニング、シャーディング | partitioning / sharding | — | 1 つの表を範囲やハッシュで分ける / 複数のノードに分ける | DB をサービスごとに分けるのはどちらでもない。「分離」と書く |
| マテリアライズドビュー | materialized view | — | 問い合わせの結果を表として保存する | readmodel の一形態 |
| オンライン DDL | online DDL | MySQL 5.6（2013）以降の機能名 | 読み書きを止めずにスキーマを変える | DB マイグレーションの表と同じ |
| CQRS | Command Query Responsibility Segregation | Greg Young（2010） | 書きと読みのモデルを分ける | CQS（Meyer）はメソッドの原則、CQRS はアーキテクチャ。greenfield は CQS |
| イベントソーシング | event sourcing | Martin Fowler, bliki（2005） | 状態でなく出来事の列を保存する | 複式簿記からの説明は別の記事 |
| 冪等 | idempotent | Benjamin Peirce（1870、代数学） | 何度適用しても結果が同じ | 冪等キー、Idempotent Receiver |
グラフ理論と統計（構造の分析で使うもの）
| 標準の語 | 原語 | 出典（著者・年） | 意味 | この文書群での対応 |
|---|
| グラフ、頂点、辺 | graph / vertex / edge | Euler（1736）に始まる | 点と、点をつなぐ線 | テーブルを頂点、外部キーを辺にする |
| 次数 | degree | — | 頂点につながる辺の数 | hub の判定（次数の閾値） |
| 連結成分 | connected component | — | 互いに辿れる頂点の集まり | 孤立テーブル = 大きさ 1 の成分 |
| 橋、2-辺連結成分 | bridge / 2-edge-connected component | Tarjan（1974） | 取ると分断される辺 / 橋を含まない塊 | 切断点、ブロック |
| 媒介中心性 | betweenness centrality | Linton Freeman（1977） | 最短経路がどれだけその辺（頂点）を通るか | Girvan–Newman の判定基準 |
| コミュニティ検出 | community detection | — | 内側が密で外とは疎な部分集合を見つける | 分割案 |
| Girvan–Newman 法 | Girvan–Newman algorithm | Girvan & Newman（2002） | 媒介中心性の高い辺から順に取り除く | 決定的なので採用。大規模では遅い |
| モジュラリティ Q | modularity | Newman & Girvan（2004） | 分割の良さ。偶然より内側の辺がどれだけ多いか | 0.3 以上で構造あり、の目安 |
| Louvain 法 / Leiden 法 | Louvain / Leiden | Blondel ほか（2008）/ Traag ほか（2019） | モジュラリティを貪欲に最適化する速い手法 | 大規模入力の代替候補 |
| 調整済みランド指数 | adjusted Rand index（ARI） | Hubert & Arabie（1985） | 2 つの分割の一致度。1 で同じ、0 で偶然と同程度 | Physical × Logical の比較 |
| 自己相互情報量、NPMI | pointwise mutual information / normalized PMI | Church & Hanks（1990）。正規化は Bouma（2009） | 2 つの出来事が偶然より一緒に起きる度合い | 同一トランザクション共起の重み |
| 変異テスト | mutation testing | DeMillo, Lipton, Sayward（1978） | コードを少し壊してテストが落ちるかを見る | ゲート自身を壊して確かめる |
ネットワークとプロトコル
| 標準の語 | 原語 | 出典（著者・年） | 意味 | この文書群での対応 |
|---|
| TCP/IP | Transmission Control Protocol / Internet Protocol | Cerf & Kahn（1974）。RFC 791 / 793（1981） | インターネットの基盤。IP が届け、TCP が順序と再送を保証する | |
| OSI 参照モデル | OSI reference model | ISO 7498（1984） | 7 層のモデル。L4 / L7 の呼び方の由来 | ALB は L7、NLB は L4 |
| DNS、名前解決 | Domain Name System / name resolution | Paul Mockapetris, RFC 1034 / 1035（1987） | 名前から IP アドレスを引く | issuer の名前を全員が同じ名前で解決できることが要る |
| スプリットホライズン DNS | split-horizon DNS | — | 同じ名前を、問い合わせ元の場所によって別の宛先に解決する | 本番で Keycloak の issuer を 1 つに固定しつつ VPC 内から到達させる手段 |
| TTL | time to live | IP ヘッダ（RFC 791）。DNS のキャッシュ期間にも転用 | 生存時間。期限が来たら捨てる | DNS キャッシュ、フラグ定義のキャッシュ |
| HTTP | Hypertext Transfer Protocol | Berners-Lee（1991）。現行は RFC 9110–9112（2022） | Web の要求と応答 | |
| HTTP/2、SETTINGS | HTTP/2 | RFC 7540（2015）→ RFC 9113（2022） | 1 接続で多重化する版。SETTINGS フレームは接続の設定交換 | CVE-2026-78669 は SETTINGS の洪水による DoS |
| TLS、終端 | Transport Layer Security / TLS termination | RFC 8446（TLS 1.3、2018） | 通信の暗号化と相手の認証 / 暗号化を解く場所 | ALB の 3 責務の 1 つ。アプリは TLS を知らない |
| mTLS | mutual TLS | TLS の仕様内（クライアント証明書） | 双方が証明書で認証する | サービス間認証の代替案。greenfield は M2M トークンを選んだ |
| リバースプロキシ、ロードバランサ | reverse proxy / load balancer | — | 手前で受けて振り分ける | Caddy（ローカル）、ALB（AWS） |
| CIDR、サブネット | Classless Inter-Domain Routing / subnet | RFC 1519（1993）→ RFC 4632 | アドレスの範囲の書き方 / 分けた範囲 | VPC の設計 |
| NAT | network address translation | RFC 1631（1994） | 内側のアドレスを外側に変換する | NAT Gateway を置かない判断（費用） |
| VPC、セキュリティグループ | virtual private cloud / security group | AWS の語（2009） | 仮想ネットワーク / インスタンス単位のステートフルな到達制御 | 到達制御は SG で行う |
| Transit Gateway（TGW） | AWS Transit Gateway | AWS（2018） | 複数の VPC とアカウントをハブで接続する | 本番系の接続方式。greenfield は模擬しない |
| PrivateLink、VPC エンドポイント | AWS PrivateLink / VPC endpoint | AWS（2017） | インターネットを通さずにサービスへ到達する | SNS / SQS をアカウント越えで使うときの選択肢 |
| ingress / egress | ingress / egress | — | 入ってくる通信 / 出ていく通信 | 英語のまま。「イングレス」と書かない |
| idle timeout、keep-alive | idle timeout / keep-alive | HTTP/1.1（RFC 2068、1997）で keep-alive が既定 | 無通信で切る時間 / 接続を使い回す | ALB の idle timeout とアプリのタイムアウトヒエラルキー |
| Cookie、SameSite | HTTP cookie / SameSite | RFC 6265（2011）。SameSite は RFC 6265bis | ブラウザが保持する小さな状態 / 他サイトからの送信制限 | SSR はブラウザに Cookie だけを渡す |
| CORS | Cross-Origin Resource Sharing | W3C（2014）→ Fetch Standard | 他オリジンからの読み取りをサーバが許可する仕組み | |
| OAuth 2.0、OIDC | OAuth 2.0 / OpenID Connect | RFC 6749（2012）/ OpenID Foundation（2014） | 認可の委譲 / その上の認証層 | 認証・認可の表と同じ |
| JWT、JWKS | JSON Web Token / JSON Web Key Set | RFC 7519 / RFC 7517（2015） | 署名付きのクレーム / 検証用の公開鍵の集合 | issuer の JWKS を取って JWT を検証する |
| PKCE | Proof Key for Code Exchange | RFC 7636（2015） | 認可コードの横取りを防ぐ | SSR と agent クライアント |
| client_credentials | client credentials grant | RFC 6749 §4.4 | サービス自身がトークンを得る | M2M |
| ステップアップ認証チャレンジ | OAuth 2.0 Step Up Authentication Challenge | RFC 9470（2023） | 401 で acr_values を要求し、再認証後に通す | 危険操作の前の AAL2 要求 |
| Problem Details | Problem Details for HTTP APIs | RFC 7807（2016）→ RFC 9457（2023） | エラー応答の標準形式 | 「エラーは problem で返す」。パニックも problem に変換する |
Idempotency-Key | Idempotency-Key header | IETF draft（draft-ietf-httpapi-idempotency-key-header） | 同じ要求の再送を同一と見なすヘッダ | サービス間の紐付け |
traceparent | W3C Trace Context | W3C 勧告（2020） | trace-id と parent-id を運ぶヘッダ | 可観測性の表と同じ。壊れていれば捨てて採番し直す |
| バックプレッシャー | backpressure | Reactive Streams（2014）で定式化 | 受け手が処理できる量まで送り手を抑える | キューの消費速度、relay のバックオフ |
| レイテンシ、スループット | latency / throughput | — | 1 件にかかる時間 / 単位時間あたりの件数 | 「rps」「p99」のように単位を添える |
OS とランタイム
| 標準の語 | 原語 | 出典（著者・年） | 意味 | この文書群での対応 |
|---|
| プロセス、スレッド | process / thread | Unix（1971–）。POSIX スレッド（1995） | 独立したアドレス空間を持つ実行単位 / その中の実行の流れ | allinone は 1 プロセスに複数サービス |
| カーネル空間、ユーザー空間、システムコール | kernel / user space、system call | — | OS の中 / アプリの側 / その境界を越える呼び出し | |
| 標準入出力、標準エラー | stdin / stdout / stderr | Unix | プロセスの 3 つの既定ストリーム | ログは stdout だけ。stderr と混ぜると行の順序が保証されない |
| 終了コード | exit status | Unix。0 が成功 | プロセスが返す整数 | go run は終了コードを伝播しないので先にビルドする |
| シグナル | signal（SIGTERM / SIGINT / SIGKILL） | Unix。POSIX.1 | プロセスへの非同期の通知 | SIGTERM を受けてグレースフルシャットダウン。SIGKILL は捕まえられない |
| 環境変数 | environment variable | Unix | プロセスに渡す名前と値の組 | つなぎ先は全部環境変数。秘密は SSM から |
| パイプ、リダイレクト | pipe / redirect | Unix（1973） | プロセスの出力を次の入力へ / ファイルへ | tee でログをファイルにも書く |
| ソケット | socket | BSD 4.2（1983） | 通信の端点 | Listen するポートだけをアプリが知る |
| ファイルディスクリプタ、ulimit | file descriptor / ulimit | Unix | 開いたファイルや接続の番号 / その上限 | 接続プールの上限と合わせる |
| 名前空間、cgroups | namespaces / control groups | Linux（namespaces 2002–、cgroups 2007） | 見える範囲を分ける / 資源を制限する | コンテナの実体 |
| コンテナ、イメージ、OCI | container / image / Open Container Initiative | Docker（2013）。OCI（2015） | 名前空間と cgroups で隔離した実行環境 / その雛形 / 標準規格 | Dockerfile、ECR、digest |
| 非 root、capabilities | non-root / Linux capabilities | Linux 2.2（1999） | 管理者権限で動かさない / 権限を細かく分ける | 最終ステージに USER。secure-defaults の検査 |
| 読み取り専用ルートファイルシステム | read-only root filesystem | — | コンテナの / を書き込み不可にする | 非 root とセットで設計 |
| 競合状態 | race condition | — | 実行の順序で結果が変わる不具合 | |
| TOCTOU | time-of-check to time-of-use | McPhee（1974）に遡る | 確認と使用の間に状態が変わる競合 | シンボリックリンクの差し替えなど。検査の後に対象が変わる |
| デッドロックの 4 条件 | Coffman conditions | Coffman, Elphick, Shoshani（1971） | 相互排除・保持と待機・横取り不可・循環待ち | DB のデッドロックも同じ条件 |
| 時刻：壁時計と単調時計 | wall clock / monotonic clock | — | 現在時刻 / 進むだけで戻らない時計 | 経過時間は単調時計で測る。デッドライン伝播を相対時間にする理由 |
| UTC、RFC 3339、ISO 8601 | — | ISO 8601（1988）。RFC 3339（2002） | 協定世界時 / 日時の文字列形式 | ログの時刻は RFC 3339 の UTC 固定 |
| NTP、時計のずれ | Network Time Protocol / clock skew | RFC 958（1985）→ RFC 5905 | 時刻を合わせる / サーバ間の差 | 絶対時刻でデッドラインを送らない理由 |
| fsync、ページキャッシュ | fsync / page cache | Unix | ディスクへ書き切る / OS がメモリに持つファイルの写し | 永続性（ACID の D）の実装 |
| OOM killer | out-of-memory killer | Linux | メモリ不足時にプロセスを強制終了する | メモリ上限と cgroups |
| 単一障害点 | single point of failure（SPOF） | — | そこが落ちると全体が止まる要素 | Single-AZ の RDS は検証用。Multi-AZ の実測 |
古典の書籍の語
設計の語の多くは特定の本が定義し、その邦訳が定訳になっている。本ごとに、
この文書群で使う語と、コードの中での対応を書く。
PoEAA — Fowler『エンタープライズアプリケーションアーキテクチャパターン』
Martin Fowler, Patterns of Enterprise Application Architecture（Addison-Wesley, 2002）。
邦訳は翔泳社（2005）。パターン名はこの邦訳の表記に従う。
| 標準の語（定訳） | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| ドメインモデル | Domain Model | 振る舞いとデータを持つオブジェクトでドメインを表す | domain パッケージ。書き込み経路だけが通る | ドメインオブジェクト層 |
| トランザクションスクリプト | Transaction Script | 手続きを 1 本の関数で書く | usecase が長くなったときの退化形として対比に使う | 手続き型 |
| サービスレイヤ | Service Layer | アプリケーションの操作の入口を定義する層 | usecase。業務の手順を持ち、バージョンを持たない | サービス層 |
| アクティブレコード | Active Record | 行に対応するオブジェクトが自分で DB を読み書きする | Yii 1.x / Rails の ORM の型。habakiri の解析対象 | ActiveRecord（クラス名として書くとき以外） |
| データマッパー | Data Mapper | オブジェクトと DB の対応を別の層が担う | sqlc の生成コード + repository | ORM（一般語なので限定して使う） |
| リポジトリ | Repository | コレクションのようにオブジェクトを出し入れする口 | repository。Atomic な書き込み | DAO（別のパターン） |
| ユニットオブワーク | Unit of Work | 1 業務の変更をまとめて 1 トランザクションで確定する | Atomic.Do。outbox への追記も同じトランザクション | 作業単位 |
| アイデンティティマップ | Identity Map | 同じ行を 1 トランザクション内で 1 つのオブジェクトに保つ | 使っていない。対比でのみ | |
| レイジーロード | Lazy Load | 必要になるまで読み込みを遅らせる | ORM の挙動として言及するとき | 遅延読み込み（併記は可） |
| 楽観的オフラインロック | Optimistic Offline Lock | バージョン番号で競合を検出する | 冪等キーと組み合わせる場面で | 楽観ロック（併記は可） |
| 悲観的オフラインロック | Pessimistic Offline Lock | 先にロックを取って競合を防ぐ | DDL のロック待ち（1205）の対比で | 悲観ロック（併記は可） |
| ゲートウェイ | Gateway | 外部システムへのアクセスを 1 つのオブジェクトに包む | gearlink（他サービスの client）、blobstore | ラッパー |
| リモートファサード | Remote Facade | 粗い粒度のリモート呼び出し口 | internal リスナーの API | |
| データトランスファーオブジェクト | Data Transfer Object（DTO） | 呼び出しの間でデータを運ぶだけのオブジェクト | huma の入出力型。「DTO」と略してよい | 転送オブジェクト |
| セパレートインタフェース | Separated Interface | インタフェースと実装を別のパッケージに置く | 差し込み口（consistency.Bus、blobstore、flagsource）。core は口だけを持つ | 差し込み口（独自語なので初出で対応を書く） |
| プラグイン | Plugin | 実装を設定で差し替える | eventbus/snssqs のような実装モジュール | |
| レジストリ | Registry | よく使うオブジェクトを探すための既知の場所 | 使っていない。グローバルの TracerProvider は後勝ちになるので明示渡しにした | |
| バリューオブジェクト | Value Object | 同一性でなく値で比べる小さなオブジェクト | DDD の値オブジェクトと同じ | 値型 |
| スペシャルケース | Special Case | null の代わりに特別な振る舞いを持つオブジェクトを返す | no-op の Tracer | ヌルオブジェクト（併記は可） |
| フロントコントローラ | Front Controller | 全リクエストを 1 か所で受けて振り分ける | core/httpapi のルータと基盤ミドルウェア | |
DDD — Evans『エリック・エヴァンスのドメイン駆動設計』
Eric Evans, Domain-Driven Design（Addison-Wesley, 2003）。邦訳は翔泳社（2011）。
| 標準の語（定訳） | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| エンティティ | Entity | 同一性で識別されるオブジェクト | domain の型 | |
| 値オブジェクト | Value Object | 値で比べるオブジェクト | PoEAA のバリューオブジェクトと同じ。表記は「値オブジェクト」 | |
| 集約 | Aggregate | 1 つのトランザクションで整合を保つ境界 | Atomic の範囲。FK グラフから集約の境界を推定する話は habakiri | アグリゲート |
| リポジトリ | Repository | 集約の出し入れ口 | PoEAA と同じ | |
| ドメインサービス | Domain Service | エンティティに属さない業務の操作 | | |
| 境界づけられたコンテキスト | Bounded Context | モデルが一貫して通用する範囲 | サービス（photo / gear）の単位 | 境界コンテキスト、バウンデッドコンテキスト |
| ユビキタス言語 | Ubiquitous Language | チームとコードで同じ語を使うこと | この用語表の目的 | 共通言語 |
| コンテキストマップ | Context Map | コンテキスト間の関係の図 | C4 の Context 図に相当する部分 | |
| 共有カーネル | Shared Kernel | 複数のコンテキストが共有するモデル | hub として割らないテーブル群 | 共通部品 |
| 腐敗防止層 | Anti-Corruption Layer | 他コンテキストのモデルを変換して受ける層 | replicaview（他サービス由来の表示用データ） | ACL |
| 公開ホストサービス | Open Host Service | 他コンテキスト向けに公開する一連のサービス | internal API | |
| 公表された言語 | Published Language | コンテキスト間でやり取りする共通の形式 | OpenAPI、イベントの envelope | |
EIP — Hohpe & Woolf『Enterprise Integration Patterns』
Gregor Hohpe, Bobby Woolf, Enterprise Integration Patterns（Addison-Wesley, 2003）。
パターン名は英語のまま使う（邦訳の表記が定着していない）。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| Publish-Subscribe Channel | 同 | 1 つのメッセージを複数の受け手へ | SNS トピック → 受け手ごとの SQS キュー | pub/sub（略記は可） |
| Point-to-Point Channel | 同 | 1 つのメッセージを 1 つの受け手へ | SQS キュー | |
| Guaranteed Delivery | 同 | 送り手が落ちてもメッセージを失わない | outbox（DB に永続化してから送る） | 到達保証 |
| Transactional Client | 同 | メッセージの送受信をトランザクションに含める | outbox への追記を業務のトランザクションに含める | |
| Idempotent Receiver | 同 | 同じメッセージを 2 回受けても結果が 1 回分 | inbox による重複排除 | 冪等な受信者 |
| Competing Consumers | 同 | 複数の受け手が 1 つのキューを分担する | SQS の consumer を複数にしたとき | |
| Polling Consumer | 同 | 受け手が能動的に取りに行く | gear の consumer | ポーリング |
| Correlation Identifier | 同 | 要求と応答・ログを結ぶ ID | trace_id（W3C Trace Context） | 相関 ID（併記は可） |
| Dead Letter Channel | 同 | 処理できないメッセージの退避先 | SQS の dead-letter queue | デッドレター（併記は可） |
| Message Translator | 同 | 形式を変換する | 腐敗防止層の実装手段 | |
Release It! — Nygard
Michael T. Nygard, Release It!（Pragmatic Bookshelf, 2007、第 2 版 2018）。邦訳はオーム社（2009）。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| サーキットブレーカー | Circuit Breaker | 失敗が続く呼び先への呼び出しを遮断する | 可観測性の表と同じ | 遮断器 |
| バルクヘッド | Bulkhead | 障害を区画に閉じ込める | DB 接続プールのサービス分離 | 隔壁 |
| タイムアウト | Timeouts | 待ち続けない | タイムアウトヒエラルキー、デッドライン伝播 | |
| フェイルファスト | Fail Fast | 続行できないならすぐ失敗する | 通らない DDL をエラーで返す | 早期失敗 |
| 定常状態 | Steady State | 人手なしで動き続けられる状態 | 回収ジョブ、ログの保持期間 | |
| ハンドシェイク | Handshaking | 受け付けられるかを先に確かめる | readiness | |
継続的デリバリー — Humble & Farley
Jez Humble, David Farley, Continuous Delivery（Addison-Wesley, 2010）。邦訳は
アスキー・メディアワークス（2012）。Blue/Green とカナリアの出典はここである。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| デプロイメントパイプライン | deployment pipeline | コミットから本番までの自動化された段 | CI → image-release → deploy.yml | ビルドパイプライン |
| コミットステージ | commit stage | コミットごとに走る最初の検査 | mise run check と CI | |
| Blue/Green デプロイ | blue-green deployment | 新旧 2 系統を並走させて切り替える | デリバリーの表と同じ | |
| カナリアリリース | canary releasing | 一部のユーザーにだけ新版を出す | デリバリーの表のカナリア | |
| 構成管理 | configuration management | 環境と設定をコードで管理する | compose、Terraform、realm-as-code | |
ヘキサゴナル / クリーンアーキテクチャ
Alistair Cockburn, Hexagonal Architecture（2005）。Robert C. Martin, Clean Architecture
（Prentice Hall, 2017。邦訳はアスキードワンゴ、2018）。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| ポートとアダプタ | Ports and Adapters | 中心のロジックを口（ポート）で囲み、外側の実装（アダプタ）を差し替える | handler は HTTP のアダプタ。v1 / v2 は同じ usecase への別アダプタ | ヘキサゴナル（通称。初出で併記） |
| ユースケース | Use Case | アプリケーション固有の業務の手順 | usecase パッケージ | アプリケーションサービス（DDD の語。同じものを指すときは usecase に寄せる） |
| 依存の向き | dependency rule | 内側は外側を知らない | core は差し込み口だけを持ち、実装は外のモジュール | |
もっと古い古典 — 1960〜90 年代の論文と本
上の本が前提にしている語。原典の著者と年を添える。
| 標準の語 | 原語 | 出典（著者・年） | 意味 | この文書群での対応 |
|---|
| コンウェイの法則 | Conway’s law | Melvin Conway, “How Do Committees Invent?”（1968） | システムの構造は、それを作る組織の通信構造を写す | サービスの境界とチームの境界を合わせる話。チームトポロジーの前提 |
| 情報隠蔽 | information hiding | David Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”（1972） | 変わりやすい決定をモジュールの中に閉じ込める。分解の基準 | モジュール境界を機械で守る理由。マイクロサービスの表と同じ |
| 結合度、凝集度 | coupling / cohesion | Yourdon & Constantine, Structured Design（1979。Constantine の 1960 年代後半の仕事に基づく） | モジュール間の依存の強さ / モジュール内の関連の強さ | 疎結合・高凝集。コナーセンスはこれを細かくしたもの |
| 関心の分離 | separation of concerns | Edsger Dijkstra, “On the role of scientific thought”（1974） | 1 つの側面ずつ考えられるように分ける | 横断的関心事（core）と業務（usecase / domain）を分ける |
| 構造化プログラミング | structured programming | Dijkstra, Dahl, Hoare, Structured Programming（1972） | goto を使わず、順次・分岐・反復で組む | |
| 人月の神話 | The Mythical Man-Month | Frederick Brooks（1975。邦訳『人月の神話』） | 人と月は交換できない | 書名として使う |
| ブルックスの法則 | Brooks’s law | 同上 | 遅れたプロジェクトに人を足すとさらに遅れる | |
| 概念的統一性 | conceptual integrity | 同上 | 設計が 1 つの考えで貫かれていること | 規約と ADR を 1 か所に持つ理由 |
| セカンドシステム効果 | second-system effect | 同上 | 2 作目は機能を盛りすぎる | 螺旋の歴史で扱う |
| 本質的複雑性 / 偶有的複雑性 | essential / accidental complexity | Brooks, “No Silver Bullet”（1986） | 問題そのものの難しさ / 道具や表現が生む難しさ | 道具で消せるのは偶有的なものだけ |
| 銀の弾などない | No Silver Bullet | 同上 | 1 桁の生産性向上をもたらす単一の技術は無い | |
| ソフトウェア進化の法則 | Lehman’s laws of software evolution | Meir Lehman（1974 / 1980） | 使われるシステムは変わり続け、何もしなければ複雑さは増す | 進化的アーキテクチャの前提。「設計は放っておくと崩れる」 |
| ウォーターフォール | waterfall | Winston Royce（1970。本人は改良版を提案していた） | 工程を順に 1 回ずつ通す | 螺旋の歴史で扱う |
| スパイラルモデル | spiral model | Barry Boehm（1986） | リスク駆動で反復する | 同上 |
| 早すぎる最適化 | premature optimization | Donald Knuth（1974） | 測る前に最適化しない | 「測れることは測ってから主張する」 |
| 堅牢性の原則 | robustness principle（Postel’s law） | Jon Postel, RFC 761（1980）、RFC 1122（1989） | 送るときは厳密に、受けるときは寛容に | 壊れた traceparent は黙って捨てて採番し直す。ただし境界では厳密さを優先する場面もある |
| エンドツーエンド原則 | end-to-end argument | Saltzer, Reed, Clark, “End-to-End Arguments in System Design”（1984） | 正しさの保証は端点でしか完結しない。途中で頑張っても端点の検査は要る | at-least-once の配送と受信側の inbox。配送基盤に exactly-once を求めない |
| 論理時計、happened-before | logical clocks / happened-before | Leslie Lamport, “Time, Clocks, and the Ordering of Events in a Distributed System”（1978） | 分散した出来事の順序は物理時刻で決められない | 順序保証、デッドライン伝播を相対時間にする理由 |
| ACID | atomicity / consistency / isolation / durability | Haerder & Reuter（1983）。Jim Gray, “The Transaction Concept”（1981） | トランザクションの 4 性質 | Atomic の範囲。outbox を同じトランザクションに含める |
| 2 相コミット | two-phase commit（2PC） | Gray（1978）ほか | 複数の資源にまたがる原子的な確定 | 使わない。outbox で代替する理由として言及 |
| 契約による設計 | design by contract | Bertrand Meyer, Object-Oriented Software Construction（1988 / 1997） | 事前条件・事後条件・不変条件で振る舞いを約束する | API の「契約」という語の由来 |
| コマンドクエリ分離 | command-query separation（CQS） | 同上 | 状態を変える操作と値を返す操作を分ける | ADR 0005。repository（書き）と readmodel（読み）。CQRS とは別の語 |
| CAP | consistency / availability / partition tolerance | Eric Brewer（2000） | 分断時に一貫性と可用性は両立しない | 結果整合性を選ぶ根拠 |
| 結果整合性（原典） | eventually consistent | Werner Vogels, “Eventually Consistent”（2008） | 更新が止まれば全レプリカは同じ値に収束する | データ連携の表と同じ |
| デザインパターン | design patterns | Gamma, Helm, Johnson, Vlissides（1994。邦訳『オブジェクト指向における再利用のためのデザインパターン』） | 再利用できる設計の型 23 種 | 次の行で使うものだけ |
| アダプタ、ファサード、デコレータ、ストラテジ | Adapter / Facade / Decorator / Strategy | 同上 | 変換して合わせる / 入口を 1 つに / 振る舞いを包んで足す / 差し替え可能な手順 | handler はアダプタ、ミドルウェアはデコレータ、差し込み口の実装はストラテジ |
| シングルトン | Singleton | 同上 | インスタンスを 1 つに限る | グローバルの TracerProvider は後勝ちになるので使わず、明示渡しにした |
設計原則 — SOLID とその周辺
原則は 1 冊の本ではなく、論文や記事が出どころである。略語はそのまま使い、初出で展開する。
| 標準の語 | 原語 | 出典（著者・年） | 意味 | この文書群での対応 |
|---|
| SOLID | — | 原則は Robert C. Martin がまとめた（2000 年ごろ、Agile Software Development 2003）。頭字語は Michael Feathers | 下の 5 原則の総称 | 略語のまま。「SOLID 原則」と書く |
| 単一責任の原則 | single responsibility principle（SRP） | Martin（2003）。Parnas の情報隠蔽と DeMarco の凝集に由来 | モジュールを変える理由は 1 つであるべき | core/logger 以外の core はログしない、のような「誰が何をするか」の線引き |
| 開放閉鎖の原則 | open-closed principle（OCP） | Bertrand Meyer, Object-Oriented Software Construction（1988） | 拡張に開き、修正に閉じる | 差し込み口（consistency.Bus など）に実装を足し、core は変えない |
| リスコフの置換原則 | Liskov substitution principle（LSP） | Barbara Liskov（1987）。Liskov & Wing, “A Behavioral Notion of Subtyping”（1994） | 派生型は基底型の約束を破らずに置き換えられる | v2 アダプタは同じ usecase の約束を守る。契約による設計と対で読む |
| インタフェース分離の原則 | interface segregation principle（ISP） | Martin（1996） | 使わないメソッドに依存させない | Bus と Handler を別のインタフェースにする |
| 依存性逆転の原則 | dependency inversion principle（DIP） | Martin, “The Dependency Inversion Principle”（1996） | 上位は下位の実装でなく抽象に依存する | core が口を持ち、実装モジュールが core に依存する（ADR 0022） |
| 依存性注入 | dependency injection（DI） | Martin Fowler, “Inversion of Control Containers and the Dependency Injection pattern”（2004） | 依存を外から渡す | 合成ルート（cmd / app）で組み立てる。TracerProvider の明示渡し |
| 制御の反転 | inversion of control（IoC） | Fowler（2004）。語は Johnson & Foote（1988） | 呼ぶ側と呼ばれる側を逆にする。フレームワークが自分のコードを呼ぶ | DI と区別する。IoC は性質、DI はその一手法 |
| 合成ルート | composition root | Mark Seemann, Dependency Injection in .NET（2011） | 依存を組み立てる唯一の場所 | 各サービスの cmd / app（ADR 0003） |
| 非循環依存の原則 | acyclic dependencies principle（ADP） | Martin（1996、パッケージ原則） | モジュールの依存に循環を作らない | go.mod の replace から作る依存グラフ。affected の前提 |
| 安定依存の原則 | stable dependencies principle（SDP） | 同上 | 変わりやすいものから変わりにくいものへ依存する | core は軽依存に保つ |
| DRY | Don’t Repeat Yourself | Hunt & Thomas, The Pragmatic Programmer（1999） | 知識の表現を 1 か所にする | タイトル規約を schema と検査スクリプトで同じ関数にする |
| KISS | Keep It Simple, Stupid | Kelly Johnson（1960 年代、Lockheed） | 単純に保つ | |
| デメテルの法則 | Law of Demeter | Lieberherr, Holland, Riel（1988） | 直接の相手にだけ話す。a.b().c().d() を書かない | |
| Tell, Don’t Ask | Tell, Don’t Ask | Andy Hunt & Dave Thomas（Pragmatic Programmers, 2003） | 状態を聞いて判断せず、やってほしいことを伝える | ドメインモデルに振る舞いを置く理由 |
| 継承より合成 | composition over inheritance | GoF（1994）の原則の一つ | 振る舞いの再利用は継承でなく合成で | ミドルウェアはデコレータで積む |
| 最小驚き | principle of least astonishment | 1960 年代後半から。Geoffrey James, The Tao of Programming（1987）などで定式化 | 使う人が驚かない振る舞いにする | 既定値の決め方 |
| 最小権限 | principle of least privilege | Saltzer & Schroeder, “The Protection of Information in Computer Systems”（1975） | 必要な権限だけを与える | task role、スコープ internal:*、非 root |
| フェイルセーフ既定値 | fail-safe defaults | 同上（1975） | 許可は明示、既定は拒否 | fail closed の原典。「未設定は本番として扱う」（ADR 0016） |
| 多層防御 | defense in depth | 軍事用語から。NSA の文書（2000 年代）で定式化 | 1 つの防御に頼らない | ネットワーク・認証・認可・DB の GRANT を重ねる |
| ゼロトラスト | zero trust | John Kindervag, Forrester（2010） | ネットワークの位置を信用しない | 「到達制御の実効性はネットワーク層でなく GRANT・scope・JWT 検証に置く」 |
リファクタリング — Fowler『リファクタリング』
Martin Fowler, Refactoring: Improving the Design of Existing Code（Addison-Wesley, 1999 / 2nd ed. 2018）。
邦訳『リファクタリング（第 2 版）』（オーム社, 2019）。臭いとリファクタリングの名前は第 2 版の邦訳に従う。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| リファクタリング | refactoring | 外から見た振る舞いを変えずに内部構造を変える。小さな手順の名前付きカタログ | 「用語を直す」「ファイルを移す」はリファクタリングではない | リファクタ、作り直し |
| 2 つの帽子 | two hats | 機能追加とリファクタリングを同時にやらない | PR を「振る舞いの変更」と「構造の変更」で分ける | |
| 準備のためのリファクタリング | preparatory refactoring | 変更を楽にするために先に構造を直す | expand の前の整理 | |
| 機会的リファクタリング | opportunistic refactoring | 触ったついでに少し良くする | ボーイスカウトルールと同じ | |
| コードの臭い | code smell | 構造に問題がある兆候。語は Kent Beck | 臭いの名前は下の行の表記で | コードスメル（併記は可） |
| 重複したコード | Duplicated Code | 同じ知識が複数の場所にある | DRY と対で読む | 重複コード |
| 長い関数 | Long Function | 1 つの関数が長すぎる | 第 1 版は「長いメソッド」 | |
| 変更の偏り | Divergent Change | 1 つのモジュールが別々の理由で何度も変わる | 単一責任の原則の裏返し | 発散的変更 |
| 変更の分散 | Shotgun Surgery | 1 つの変更のために多くのモジュールを触る | 境界の引き直しドリルで数えた「34 ファイル・230 箇所」はこの臭い | 散弾銃手術 |
| 特性の横恋慕 | Feature Envy | 他のオブジェクトのデータばかり使う | ドメインモデルに振る舞いを置く理由 | 属性の横恋慕 |
| データの群れ | Data Clumps | いつも一緒に現れるデータの組 | パラメータオブジェクトの導入へ | |
| 基本データ型への執着 | Primitive Obsession | ID や金額を文字列や数値のまま持つ | 値オブジェクトへ | プリミティブ型への執着 |
| 疑わしき一般化 | Speculative Generality | いつか使うための仕組み | YAGNI と対で読む。「使われない公開 API を先に生やさない」 | |
| メッセージの連鎖 | Message Chains | a.b().c().d() | デメテルの法則と対で読む | |
| 仲介人 | Middle Man | 委譲するだけのクラス | | |
| 内部的相互依存 | Insider Trading | モジュールどうしが内部をやり取りしすぎる | 境界を越える import を lint で止める | 不適切な関係（第 1 版） |
| データクラス | Data Class | データだけで振る舞いが無いクラス | DTO は意図的なデータクラス | |
| 関数の抽出 | Extract Function | 関数の一部を名前付きの関数にする | 第 1 版は「メソッドの抽出」 | |
| 関数のインライン化 | Inline Function | 抽出の逆 | | |
| 変数名の変更 | Rename Variable | 名前を意図に合わせる | 用語表に合わせる改名はこれ | |
| 関数の移動 | Move Function | 関数を使う側に近いモジュールへ移す | | |
| クラスの抽出 | Extract Class | 責務ごとにクラスを分ける | | |
| パラメータオブジェクトの導入 | Introduce Parameter Object | データの群れを 1 つの型にする | | |
| 条件記述のポリモーフィズムによる置き換え | Replace Conditional with Polymorphism | 型による分岐を多相で置き換える | | |
| 抽象によるブランチ | Branch By Abstraction | 差し替えたいものの前に抽象を置き、新旧を並走させて切り替える | Paul Hammant（2007）、Fowler の bliki（2014）。expand/contract と同じ構造を コードで行う。長命なブランチを作らない | 抽象化ブランチ |
| 技術的負債 | technical debt | 今の近道が将来の利子になる | Ward Cunningham（1992）。Fowler は「負債の象限」（2009）で意図的 / 無謀の軸を足した | 技術的借金 |
XP と TDD — Beck『エクストリームプログラミング』『テスト駆動開発』
Kent Beck, Extreme Programming Explained（Addison-Wesley, 1999 / 2nd ed. 2004。邦訳はオーム社, 2015）、
Test-Driven Development: By Example（2002。邦訳『テスト駆動開発』オーム社, 2017）。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| 継続的インテグレーション | continuous integration（CI） | 変更を頻繁に統合し、毎回自動で検査する | CI は略語として使う。「CI が止める」 | 継続的統合 |
| テスト駆動開発 | test-driven development（TDD） | 失敗するテストを先に書き、通してから整理する | 「red / green / refactor」は英語のまま | テストファースト（手順の一部） |
| ペアプログラミング | pair programming | 2 人で 1 つのコードを書く | | ペアプロ（会話のみ） |
| 小さなリリース | small releases | 小さく頻繁に出す | デプロイ分離・プログレッシブデリバリーの背景 | |
| シンプルな設計 | simple design | 今必要なものだけを作る | | |
| YAGNI | You Aren’t Gonna Need It | 必要になるまで作らない | 英語のまま。「使われない公開 API を先に生やさない」 | |
| 共同所有 | collective ownership | コードは誰でも直してよい | | 共同所有権 |
| 持続可能なペース | sustainable pace | 残業に頼らない速さで続ける | | |
| 10 分ビルド | ten-minute build | ビルドと検査を 10 分以内に | affected で変更モジュールだけ検査する動機 | |
Google のソフトウェアエンジニアリング — Winters, Manshreck, Wright
Titus Winters, Tom Manshreck, Hyrum Wright (eds.), Software Engineering at Google
（O’Reilly, 2020）。邦訳『Googleのソフトウェアエンジニアリング』（オライリー・ジャパン, 2021）。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| ハイラムの法則 | Hyrum’s Law | 利用者が十分いれば、契約に書いていない振る舞いにも依存される | API の破壊的変更の検査を機械にする理由 | |
| トランクベース開発 | trunk-based development | 長命なブランチを作らず main に小さく入れる | PR は短命、main へ squash | |
| モノレポ | monorepo | 1 つのリポジトリで複数のシステムを持つ | 構造の表と同じ | |
| 大規模変更 | large-scale change（LSC） | リポジトリ全体に及ぶ機械的な変更 | 用語の一括修正、依存の一括更新 | |
| フレーキーテスト | flaky test | 同じコードで成功と失敗が揺れるテスト | 差分運用で「揺れる検査」を扱う話 | 不安定なテスト（併記は可） |
| テストサイズ | test sizes（small / medium / large） | 使う資源で分類する。DB を使うテストは medium 以上 | 「DB 系のテストは mysql 到達時のみ」 | 単体 / 統合（分類軸が違う） |
| 廃止 | deprecation | 古いものを計画的に止める | API の旧版は deprecated を 1 リリース挟む | 非推奨（状態の語としては可） |
| 左シフト | shift left | 問題の検出をプロセスの早い段階へ寄せる | 手元の mise run check を CI と同じにする | シフトレフト（併記は可） |
| 可読性 | readability | コードが読めることを組織で保証する仕組み | | |
| 時間で積分したプログラミング | programming integrated over time | ソフトウェアエンジニアリングの定義。寿命を考える | 適応度関数が要る理由 | |
マイクロサービス — Newman、S. Fowler
Sam Newman, Building Microservices（O’Reilly, 2015 / 2nd ed. 2021。邦訳『マイクロサービスアーキテクチャ』オライリー・ジャパン, 2016 / 2022）、
Monolith to Microservices（2019。邦訳『モノリスからマイクロサービスへ』2020）。
Susan J. Fowler, Production-Ready Microservices（O’Reilly, 2016。邦訳『プロダクションレディマイクロサービス』2017）。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| 情報隠蔽 | information hiding | 境界の内側を外に見せない | 「サービスは他サービスの内部を知らない」 | カプセル化（オブジェクトの語） |
| 疎結合、高凝集 | loose coupling / high cohesion | 境界をまたぐ依存を少なく、中は密に | モジュラリティ Q の意味 | |
| コレオグラフィ / オーケストレーション | choreography / orchestration | イベントで各自が動く / 指揮役が順に呼ぶ | outbox → SNS → SQS はコレオグラフィ | 振り付け |
| サーガ | saga | 複数サービスにまたがる処理を、補償で整合させる | pending 状態パターン、回収ジョブ | |
| コンシューマ駆動契約 | consumer-driven contracts | 利用側がテストとして契約を持つ | api:breaking は提供側の契約検査。対比で | |
| API ゲートウェイ | API gateway | 外部からの入口を 1 つに束ねる | ALB の 3 責務（TLS 終端・振り分け・到達制御） | |
| ストラングラー | strangler fig | 旧システムを少しずつ置き換える | 構造の表と同じ | |
| 並行実行 | parallel run | 新旧を同時に動かして結果を比べる | カラム改名の columncheck | |
| 合成トランザクション | synthetic transaction | 本物に似た操作を流して正しさを測る | promotion gate のフックが流すテスト書き込み | 合成監視（併記は可） |
| プロダクションレディ | production-ready | 安定性・信頼性・スケーラビリティ・耐障害性・大惨事対応・性能・監視・ドキュメントの基準を満たす | 守りの既定値の検査、Runbook、アラート | 本番対応 |
| 耐障害性 | fault tolerance | 依存先が落ちても自分は動く | フラグ基盤が死んでも既定値で稼働 | フォールトトレランス（併記は可） |
| 大惨事対応 | catastrophe-preparedness | 障害を起こしてみて備える | Multi-AZ フェイルオーバーとリストアの実測 | |
| Runbook | runbook | アラートごとの対処手順 | docs/runbooks/。英語のまま | 手順書（一般語） |
ソフトウェアアーキテクチャの基礎 / ハードパーツ — Richards, Ford ほか
Mark Richards, Neal Ford, Fundamentals of Software Architecture（O’Reilly, 2020。邦訳『ソフトウェアアーキテクチャの基礎』オライリー・ジャパン, 2022）。
Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani, Software Architecture: The Hard Parts
（O’Reilly, 2021。邦訳『ソフトウェアアーキテクチャ・ハードパーツ』2022）。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| アーキテクチャ特性 | architecture characteristics | 機能以外に満たすべき性質 | 適応度関数が測る対象 | 非機能要件（併記は可） |
| トレードオフ | trade-off | 何かを取れば何かを失う | 「すべてはトレードオフ」。ADR の「却下した代替」 | 妥協 |
| ADR | architecture decision record | 判断と根拠と却下した案を記録する | docs/adr/ | 設計判断記録（併記は可） |
| コナーセンス | connascence | 片方を変えるともう片方も変えなければならない関係 | 結合の強さの語彙。静的 / 動的 | |
| アーキテクチャ量子 | architectural quantum | 独立してデプロイでき、高凝集で、静的・動的に結合した単位 | 進化的アーキテクチャの表と同じ | |
| 静的結合 / 動的結合 | static / dynamic quantum coupling | 依存で結ばれる / 実行時の通信で結ばれる | 同期の内部 API は動的結合。契約・一貫性・通信の 3 軸 | |
| 分解 | decomposition | モノリスを部品に分ける | コンポーネントベース分解と戦術的フォーク | 分割（粒度の語と混ざる） |
| 戦術的フォーク | tactical forking | 全体を複製して不要な部分を削る分解法 | 境界の引き直しドリルの対比 | |
| データの所有権 | data ownership | どのサービスがどのテーブルに書くか | lint:queries、DB をまたぐ FK の禁止 | |
| データ分解の駆動要因 | data disintegrators / integrators | 分ける理由と、まとめる理由 | FK グラフから分割を出す話の背景 | |
| 契約（厳格 / 緩い） | strict / loose contracts | スキーマで固く結ぶか、名前だけで緩く結ぶか | OpenAPI は厳格、イベントの envelope は緩い | |
Accelerate『LeanとDevOpsの科学』— Forsgren, Humble, Kim
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate（IT Revolution, 2018）。邦訳『LeanとDevOpsの科学』（インプレス, 2018）。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| 4 つの指標 | four key metrics | デプロイ頻度・変更のリードタイム・変更失敗率・復旧時間 | デプロイ分離が効く先 | DORA 指標（併記は可） |
| デプロイ頻度 | deployment frequency | 本番へ出す回数 | | |
| 変更のリードタイム | lead time for changes | コミットから本番までの時間 | affected CI 20 秒、独立ロールバック 32 秒 | |
| 変更失敗率 | change failure rate | 本番で障害になった変更の割合 | promotion gate が下げる | |
| 復旧時間 | time to restore service | 障害から戻るまでの時間 | stopDeployment 32 秒、フラグ 14 秒 | MTTR（併記は可） |
チームトポロジー — Skelton, Pais
Matthew Skelton, Manuel Pais, Team Topologies（IT Revolution, 2019）。邦訳『チームトポロジー』（日本能率協会マネジメントセンター, 2021）。
| 標準の語 | 原語 | 意味 | この文書群での対応 | 使わない |
|---|
| ストリームアラインドチーム | stream-aligned team | 価値の流れに沿って担当するチーム | サービス単位のチーム | 機能チーム |
| プラットフォームチーム | platform team | 他チームの認知負荷を下げる基盤を提供する | platform/（authz）、Keycloak の運用 | 共通基盤チーム |
| イネイブリングチーム | enabling team | 他チームが能力を得るのを助ける | | |
| 認知負荷 | cognitive load | チームが抱えられる複雑さの量 | サービスの粒度を決める基準 | |
| チーム API | team API | チームが外に約束する接点 | internal API と Runbook | |
使わない言い換えの一覧
これまでに記事で使い、直したもの。grep で当てる対象でもある。
| 使わない | 代わりに | なぜ |
|---|
| 昇格ゲート | promotion gate | 原語が英語。訳語を作ると検索でも通じない |
| レバー、引くレバー | 手段、巻き戻しの手段、操作 | 比喩。何を指すかが文脈に依存する |
| 被弾 | 失敗したリクエスト、影響を受けた | 比喩。数字（0 / 1,679）と並べると分母が見えなくなる |
| 置く・当てる・見せる | デプロイ・トラフィック切替・リリース | 定着した語がある概念に新しい日本語動詞を当てていた |
| 配線 | 依存の解決（go.mod と import） | DI の「配線（wiring）」と紛らわしい |
| リリース列車 | リリーストレイン | カタカナが定着している |
出典
用語の意味と原語は次を参照した。表の「原語」はこれらの語に合わせている。
- Martin Fowler, Feature Toggles、ParallelChange
- Neal Ford, Rebecca Parsons, Patrick Kua, Building Evolutionary Architectures（O’Reilly, 2017）。邦訳『進化的アーキテクチャ』（オライリー・ジャパン, 2018）。適応度関数・漸進的変更・アーキテクチャ量子の定訳はこれに従う
- Amazon ECS Developer Guide。blue/green、canary、bake time、deployment lifecycle hooks、
stopDeployment
- Argo Rollouts。canary、promotion、analysis
- OpenFeature Specification。feature flag、evaluation、provider
- Google SRE Book。error budget、SLO
- NIST SP 800-63B。AAL
- W3C Trace Context。
traceparent、trace-id、span-id
- OpenTelemetry Semantic Conventions。
service.name などのフィールド名
- MySQL 8.4 Reference Manual: Online DDL Operations。
ALGORITHM=INSTANT / INPLACE / COPY
- Martin Fowler, CircuitBreaker、StranglerFigApplication
- Martin Kleppmann, Designing Data-Intensive Applications（O’Reilly, 2017）。配送の保証（at-least-once / exactly-once）と整合性の語
- Kubernetes: Liveness, Readiness, and Startup Probes
- Martin Fowler, Patterns of Enterprise Application Architecture（Addison-Wesley, 2002）。邦訳『エンタープライズアプリケーションアーキテクチャパターン』（翔泳社, 2005）。パターンの一覧は martinfowler.com/eaaCatalog
- Eric Evans, Domain-Driven Design（Addison-Wesley, 2003）。邦訳『エリック・エヴァンスのドメイン駆動設計』（翔泳社, 2011）
- Gregor Hohpe, Bobby Woolf, Enterprise Integration Patterns（Addison-Wesley, 2003）。パターンの一覧は enterpriseintegrationpatterns.com
- Michael T. Nygard, Release It!（Pragmatic Bookshelf, 2007 / 2nd ed. 2018）。邦訳（オーム社, 2009）
- Jez Humble, David Farley, Continuous Delivery（Addison-Wesley, 2010）。邦訳『継続的デリバリー』（アスキー・メディアワークス, 2012）
- Alistair Cockburn, Hexagonal Architecture（2005）
- Robert C. Martin, Clean Architecture（Prentice Hall, 2017）。邦訳（アスキードワンゴ, 2018）
- Claude Shannon, “A Mathematical Theory of Communication”（1948）。Richard Hamming（1950）。David Huffman（1952）。Lempel & Ziv（1977 / 1978）
- Edgar F. Codd, “A Relational Model of Data for Large Shared Data Banks”（1970）、正規形の論文（1971–74）。Eswaran, Gray, Lorie, Traiger, “The Notions of Consistency and Predicate Locks in a Database System”（1976）。Berenson ほか, “A Critique of ANSI SQL Isolation Levels”（1995）。Bayer & McCreight（1972）。O’Neil ほか, “The Log-Structured Merge-Tree”（1996）。Mohan ほか, “ARIES”（1992）
- Greg Young, “CQRS Documents”（2010）。Martin Fowler, Event Sourcing（2005）
- Girvan & Newman, “Community structure in social and biological networks”（2002）。Newman & Girvan（2004）。Hubert & Arabie, “Comparing partitions”（1985）。Freeman（1977）。Tarjan（1974）。Church & Hanks（1990）。DeMillo, Lipton, Sayward（1978）
- Cerf & Kahn, “A Protocol for Packet Network Intercommunication”（1974）。RFC 791 / 793（1981）、RFC 1034 / 1035（1987）、RFC 6265（2011）、RFC 6749（2012）、RFC 7519 / 7517 / 7636（2015）、RFC 8446（2018）、RFC 9110–9113（2022）、RFC 9457 / 9470（2023）。W3C Trace Context
- Coffman, Elphick, Shoshani, “System Deadlocks”（1971）。RFC 3339（2002）。OCI（2015）
- Melvin Conway, “How Do Committees Invent?”（1968）。David Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”（1972）。Yourdon & Constantine, Structured Design（1979）。Dijkstra, “On the role of scientific thought”（1974）
- Frederick Brooks, The Mythical Man-Month（1975）、“No Silver Bullet”（1986）。Meir Lehman, “Programs, Life Cycles, and Laws of Software Evolution”（1980）
- Winston Royce（1970）、Barry Boehm, “A Spiral Model of Software Development and Enhancement”（1986）。Donald Knuth, “Structured Programming with go to Statements”（1974）
- Jon Postel, RFC 761（1980）/ RFC 1122（1989）。Saltzer, Reed, Clark, “End-to-End Arguments in System Design”（1984）。Leslie Lamport, “Time, Clocks, and the Ordering of Events in a Distributed System”（1978）
- Jim Gray, “The Transaction Concept”（1981）。Haerder & Reuter, “Principles of Transaction-Oriented Database Recovery”（1983）。Eric Brewer（CAP, 2000）。Werner Vogels, “Eventually Consistent”（2008）
- Bertrand Meyer, Object-Oriented Software Construction（1988 / 1997）。Barbara Liskov（1987）、Liskov & Wing（1994）。Gamma, Helm, Johnson, Vlissides, Design Patterns（1994）
- Robert C. Martin, “The Dependency Inversion Principle”（1996）、Agile Software Development: Principles, Patterns, and Practices（2003）。Martin Fowler, Inversion of Control Containers and the Dependency Injection pattern（2004）。Mark Seemann, Dependency Injection in .NET（2011）
- Hunt & Thomas, The Pragmatic Programmer（1999）。Lieberherr, Holland, Riel, “Object-Oriented Programming: An Objective Sense of Style”（1988）
- Saltzer & Schroeder, “The Protection of Information in Computer Systems”（1975）。John Kindervag, “No More Chewy Centers”（Forrester, 2010）
- Martin Fowler, Refactoring（Addison-Wesley, 1999 / 2nd ed. 2018）。邦訳『リファクタリング（第 2 版）』（オーム社, 2019）。カタログは refactoring.com/catalog。BranchByAbstraction、TechnicalDebtQuadrant。Ward Cunningham, “The WyCash Portfolio Management System”（OOPSLA 1992）
- Kent Beck, Extreme Programming Explained（1999 / 2004）、Test-Driven Development: By Example（2002）
- Titus Winters, Tom Manshreck, Hyrum Wright (eds.), Software Engineering at Google（O’Reilly, 2020）。オンライン版
- Sam Newman, Building Microservices（O’Reilly, 2015 / 2021）、Monolith to Microservices（2019）。Susan J. Fowler, Production-Ready Microservices（O’Reilly, 2016）
- Mark Richards, Neal Ford, Fundamentals of Software Architecture（O’Reilly, 2020）。Neal Ford ほか, Software Architecture: The Hard Parts（O’Reilly, 2021）
- Nicole Forsgren, Jez Humble, Gene Kim, Accelerate（IT Revolution, 2018）
- Matthew Skelton, Manuel Pais, Team Topologies（IT Revolution, 2019）
- greenfield の文書（
docs/conventions/、ADR）。昇格シグナルなど固有語の定義元