Dev Study
← 研修トップ

境界の設計

「モジュールを分ける」の実体は何か。境界とは名前が解決される場所のことで、どこに引くかで何が機械的に届かなくなるかが決まります。REST の定義・公開の不可逆性・組織の形が設計に写ること。どれも一次ソースが何を言っていて何を言っていないかから積み上げます。

  1. 1
    境界とは、名前が解決される場所のこと
    「分ける」の実体は、名前を実体に結び付ける表を分けることです。線を引いた側は名前だけを持ち、実体は向こう側にあります。
    約 9 分
  2. 2
    すでに従っている制約 — 名前を与えると、判断ができる
    リソース風の URL を作らなくても、台数を増やせる構成なら、既に Fielding が論文で2番目に導入した制約に従っています。名前は stateless です。
    約 9 分
  3. 3
    REST と呼ばれているものの正体 — 論文は URL の付け方を決めていない
    Fielding の博士論文は REST を4つのインタフェース制約で定義しており、その4つ目が hypermedia as the engine of application state です。URL の付け方は入っていません。
    約 9 分
  4. 4
    型は、線を越えない — 届くのはバイト列だけ
    同じプロセスの中では、引数の型は言語処理系が守ります。しかし線を越えた瞬間に届くのはバイト列だけで、型は「送る側の主張」と「受ける側の解釈」の2つに分かれます。
    約 9 分
  5. 5
    分けると、何が始まるか — 線を引いた瞬間に消える3つの枠
    1つのプロセスを2つに分けると、無料で付いてきた3つの枠が消えます。同一トランザクション・呼び出しが必ず返る確実さ・型検査です。
    約 9 分
  6. 6
    公開した瞬間、相手のコードが自分の仕様になる
    内部の関数を自由に変えられるのは呼び出し元を全部書き換えられるから、公開したAPIを変えられないのは呼び出し元が誰かを知らないからです。
    約 9 分
  7. 7
    線は、引いた場所ではなく話せる場所に出る
    設計に残る境界は、設計書に引いた線ではなく、作る人たちが実際に話せる範囲に沿って出ます。線を越えて合意を取る費用が高いほど、そこが切れ目になります。
    約 9 分
  8. 8
    境界は、壁ではない — 越えてくるもの
    インタフェースが固定するのは、名前・引数・戻り値の形までです。相手がどれだけ速いかは書かれていません。だから呼ぶ側を1文字も変えなくても、線の向こうが遅くなるだけで応答が変わります。
    約 9 分
  9. 9
    待たないための2つの方法は、別のものである
    「待たない」には2つあります。呼ばれた側が自分の中で待ち方を工夫するだけのものと、呼ぶ側への約束そのものを変えるもの。前者は外から見て何も変わらず、後者は応答の意味が変わります。
    約 9 分
  10. 10
    ではどこに線を引くか — 引き返せる線と、引き返せない線
    線を引く判断は、場所の良し悪しより先に「後から引き直せるか」で二つに割れます。引き直せる線は速く決めてよく、引き直せない線だけが時間を要します。
    約 9 分