勉強日記

チラ裏

DDD Part1 Ch.1 Putting the Domain Model to Work

www.informit.com

PCB: Print-Circuit Boardのツールを作った話

  • 筆者はプリント回路板(PCB)に関するソフトウェアを作ることになった
  • 筆者はPCBについて何も知らない
    • 納期までに電気技師になれるわけもない
  • 最初は、PCB設計者に「ソフトウェアが何をすべきか正確に」説明してもらった
    • 悪手である
    • PCB設計者はソフトウェア専門家ではないため、理想のソフトウェア仕様を描けない
  • ミーティングをしているうちにあることに気づく
    • 導体である"net"でPCB上のcomponentを結続し、singnalを送るらしい
  • "net" "component" "singal" といった、PCBのドメインの言葉でオブジェクト図を描き、認識をすり合わせていくことに
  • 以下、抽出された知識
    • componentはchipとは限らない
    • netはtopologyを持つ
    • componentはpinをもち、pinはnetにつながる
    • component-netは多対多であり、pinはこれをほぐす関連クラスである
      • component 1 <>-- * pin * -- 1 net
    • componentの振る舞いは簡略化可能。入出力のpinによりきまる
    • netのhop数を計算したい
      • topologyは関係ないのでモデルから外された
  • プロトタイプはものの数日でできた
  • 具体的な動くものができたことで、下記がPCB設計者に明確に伝わるようになった
    • モデルの意味するところ
    • 動いているソフトウェアとどう関係するか
  • PCB設計者は、筆者が新しい知識をモデルやS/Wにどう盛り込むのかを理解できるようになった
  • 筆者は、PCB設計者から、具体的なFBを得られるようになった
  • モデルはその後、だんだん複雑になっていった
    • 同義語や、ちょっと変えた言葉なども盛り込まれていった
      • component instance = ref-des とか?
    • 不要な枝葉末節は含めなかった
    • 何も知らないソフトウェア屋も、モデルの図を見て数分後には、何に関するソフトウェアなのかを理解できた
  • 新しい機能が必要になると、PCB技術者たちに、モデルのオブジェクトを使ってシナリオを説明させた
  • 既存のモデルでシナリオを説明できないときは、新しいオブジェクトを作ったり、古いものを改変したりして、知識をかみ砕いた
  • モデルが洗練されるにつれ、実装コードも成長した
  • 最終的に、PCB技術者たちが予想していたものをこえるリッチなツールを納品できた

Ingredients of Effective Modeling

  1. モデルと実装とを結びつける
    • 早期にプロトタイプをつくる
  2. モデルに基づいた語彙・言語を育てる
    • 最初こそ、翻訳が必要だった
      • PCB屋にクラス図を説明する
      • ソフトウェア屋に、PCBの基礎的なことを説明する
    • じきに、モデルの語彙で直接話をできるようになった
      • 翻訳が生じないので、あいまいさが生じない
  3. 知識に富んだモデルを構築する
    • モデルのオブジェクトは振る舞いを定義し、規則を強制する
      • componentはsignalを受け取りpushする。この際、入出力のpinにより異なる振る舞いをする。
      • pinは1つのcomponentに所属し、1つのnetにつながっている
    • 単なるDTOではない
  4. モデルを蒸留・抽出する(いらないものを取り除く)
    • 必要な知識は加える
    • どうでもいい知識を取り除くことも同じくらい重要
  5. ブレインストーミングし、実験する
    • モデルの語彙で議論することそれ自体が実験になる
      • シナリオを耳で聞いたとき、明確・気楽か、ぎこちないかで、モデルの実行可能性がはかられる

Knowledge Crunching

  • 証券アナリストは、何連もの書類からなる詳細な数値の数々をいろいろ処理して、本質的に重要な情報を抽出する
  • モデラーも同じ
    • 情報の奔流から、本質的な雫を抽出する
  • 一人でやる作業ではない
    • 開発チームやドメイン専門家と一緒にやる
    • 開発主導
  • かみ砕く元の情報の出どころ
    • ドメイン専門家の脳内にある情報
    • ユーザーの既存のシステム
    • 旧システムに携わった技術チーム
    • 同じドメインの別プロジェクト
  • プロトタイピングにより...
    • FBを取り入れる
    • モデルの語彙の確認・変更
  • ウォーターフォールはFBがないため失敗する
    • モデルを作っておわり
      • プログラマから学ぶことや、プロトタイプを使って初めて気づくことが盛り込まれない
      • 知識は1方向に流れるが、蓄積しない
  • 反復型でも、知識を抽象化して構築しないと失敗する
    • リファクタリングして、拡張性を保つ必要がある
    • が、それだけでなく、ドメインに関心があることが重要
      • さもないと、古い機能の当然の結果として、新しい強力な機能を展開する、といった境地にはたどり着けない
        • 要求が降ってこないと新しい機能を作れない、うわべだけになる
  • モデルを常に洗練していくことで、否応なしに、開発者はドメインの本質を理解する
  • ドメインの専門家も、「これいる?」というのを再考させられる
  • モデルはプロジェクトをとりまく情報を整理する道具
  • モデルは要求分析に焦点をおき、設計や実装と密接
  • モデルはドメインの理解を助け、それによりモデルはより洗練される好循環
  • 完璧なモデルはない。進化していくもの
  • モデルは実用的で、ドメインを理解するうえで便利である必要がある
    • 込み入りすぎると意味がない
  • 同時に、アプリケーションの実装を単純化し、理解しやすくする程度には厳格である必要がある
    • フワフワすぎると意味がない

Continuous Learning

  • 知識の散逸
    • プロジェクトの知識は断片化し散らばっている
    • 知識が流出することがある
      • チーム再編、知っている人が散り散りに
      • 外注
        • 納品されるのはコードやバイナリだけ、知識は納品されない
    • ドメインの知識が設計やコードに残っていないと、口伝になる
      • それも途絶えると、知識は失われる
  • 生産性のよいチームメンバーはcontinuous learningを実践し、意図的に知識をつけている
  • こうして知識を蓄積することで、より効果的なknowledge cruncherになれる
  • モデルの重要性(再掲)
    • PCBの例では、netのhop数を数える機能を例に挙げた
    • 実は、この機能はそんなに重要でないことが後からわかった ... continuous learningの重要性
    • ではあのモデリング・設計は無駄だったかといえば、そうではない
      • 共通の言語で話せるようになり、以降の仕事が円滑になった

Knowledge-Rich Design

  • モデリングは「名詞を挙げてオブジェクトを割り当てる」だけではない
    • ふるまいや制約が同じくらい重要
  • ビジネスルールの矛盾等も解決して、モデルに盛り込む必要がある
    • ドメインの専門家は、彼らの常識で溝を埋めている
    • この「常識」も盛り込む必要がある
      • 制約の明確化
      • 制約の肉付け
      • 制約を調和させる
      • 関係ないので切り捨てる

船舶の貨物予約システムの例

  • ドタキャンがあるので、船舶の最大積載量よりも多く予約をとる(overbooking)のが業界の普通(ドメインの知識)
  • 「10%までoverbooking可能」というポリシーを設けるとする
  • コードにsize < max * 1.1とか書くのは良くない
  • 「ポリシー」すなわちStrategyパターンの別名なので、Strategyクラスを追加する
  • この設計の利点
    • 「10%までoverbooking可能」というのが、if文の中の不明瞭な計算ではなく、ビジネス領域での重要な制約として際立つ
    • プログラムを知らないドメイン専門家にもある程度伝えやすくなる

Deep Models

  • はじめ必要だと思ったものがあとで要らなくなる
  • はじめ思いつかなかったことが核心を突いていたりする
  • 船舶の貨物予約システムの例
    • ユーザーは、積み荷の物理的な取り回し等は、下請けにやらせていた
    • ので、下記はあまり重要ではなかった
    • むしろ下記が重要だと後で分かった
    • 旅程オブジェクト等が消えることはなかったが、モデルは大きく様変わりした
      • 積荷を場所から場所へ移動するモデルから、
        積荷の運搬の責務を下請けから別の下請けに移すモデルになった
    • 機能は、実務としっかりかみ合う内容になった

英語

  • relevant
    • 関連のある
      • つまり、要らないものじゃない、ということ
  • get one's head spinning
    • 目を回させる
  • glimmer
    • ぼんやりとした光
      • DKC2のアニマルの語源。たぶん。
    • わずかな兆し
  • iron out
    • 問題などを解決する
    • (IRON OUTという名前のさび汚れ落としが存在したりする)
  • get a grip on
    • を把握する
  • viability
    • 計画等の実行可能性
    • 生存能力
      • よい計画・悪い計画の中での生存競争を勝ち抜く可能性、という感じか
  • sift
    • ふるいにかける
  • reams of
    • 大量の
  • ream
      • 紙の単位
        • 英: 480 (short ream)
        • 米: 500 (long ream)
  • torrent
    • 奔流
  • trickle
    • ちょろちょろした流れ
    • 滴り
      • torrentと対比で使っている
  • corollary
    • 当然の結果
  • winnow
    • もみ殻を吹き分ける
    • 転じて、良いものを選別する
  • winnow out
    • 不要なものを取り除く
  • deceiving
    • 欺いている
  • at stake
    • 危機に瀕している
  • cargo
    • 船の積み荷
  • vessel
    • 船舶
  • at the outset
    • at the beginning とおなじ
  • itinerary
    • 旅程
  • consignor
    • 荷送人
  • consignee (kὰnsəníː)
    • 荷受人
  • logistic
    • 物流
  • come to the fore
    • 表面化する、目立ってくる
      • 重要な、くらいの意味か
  • bill of lading
  • release
    • 支払いを行う
  • profoundly
    • 大きく
      • profoundly changed -> ちゃぶ台がひっくり返る感じか