DDD Part1 Ch.3 Binding Model And Implementation

DDD勉強メモ

出典: 

Binding Model and Implementation

  • モデルはプロジェクト初期の分析のみならず、設計の基礎にならないと駄目だよ、という話

    • さもないと、モデルがない場合と大差ない結末に

モデルがあったが実装の役に立たなかったケース

  • 筆者は、壁一面のクソデカモデル図に出くわしたことがあった

    • その図からかなりの知識が得られた
    • が、コードや設計の深い理解には役立たなかった
    • オブジェクトの関連が絡み合いまくり

      • 1つのオブジェクトが3-4のオブジェクトと関連している
  • いざ実装してみると、モデルは役に立たなかった

    • モデルは「正しい」ものだった
    • 開発陣は、「概念的モデルは実装の役に立たない」と結論付け、その場しのぎの設計をしはじめた

      • 使用するクラス名や属性名が、DBやモデルのものと一致しない
  • 実際に動くソフトウェアの開発の役に立たないモデルにいかほどの価値がある?(いや、ない)

モデル不在のケース

  • C++からJavaへの移植案件
  • モデルなし
  • 汎化や抽象化なしに継ぎ足し継ぎ足しで作られていた

奇妙にも、できたプロダクトはそっくりだった

  • 機能は実装されている
  • が、実装が無駄に肥大化
  • 理解しづらい・保守性悪い

    • コードを読んでも意図がわからない

      • 抽象化等せず直接的に書いているのに
      • 【所感】だからこそ、では?枝葉末節に気を散らされる。
  • OOPパラダイムの利点を享受できていない

MODEL-DRIVEN DESIGN

  • コードとモデルとを強く結びつけよう

    • コードは意味を持つようになる
    • モデルはコードと同期するようになる
  • ドメインモデルなしに、機能を実現のためだけにコードを書のは駄目
  • ドメインモデルがあっても、コードと結びつかないのは駄目

    • 分析用のモデルが、次第に設計と乖離していくケース

      • モデルと設計との一致を検証することは徒労に終わる
      • というのも、「分析用のモデル」は設計・実装用ではないからである
  • 多くのモデリング方法論で、「分析用モデル」を提唱している

    • 実装は度外視される

      • 混乱を招くから (muddy the waters)
    • ので、設計・実装の役には立たない
  • モデルと設計とが強く結びついていないと…

    • モデルに盛り込んだ知識が、実装に反映され維持される保証がない

      • モデルから設計の間に翻訳作業があるから

        • 開発陣が抽象化を考えないといけない
    • 設計・実装段階での発見がモデルに反映されない

      • 分析フェーズで予期しなかった要素を盛り込む
      • 分析で挙がっていたが、実は要らなかった要素を取り除く
    • 実装が始まると、モデルは役に立たず、結局うち捨てられる
  • 設計の基礎となる概念(=モデル)を欠いたソフトウェアは、動いたとしても、正しく動いていることを保証できない
  • モデルと設計とがシンプルに対応づいていないと、仕様変更が困難
  • モデル駆動設計では、分析と設計とを分けて考えず、両目的に沿う単一のモデルを探求する

    • 分析・設計両面から

      • 重要なドメインルールを、技術的理由で妥協してはいけない
      • ソフトウェア設計の原則を度外視して、分析結果をそのままモデル化してはいけない
    • 数あるモデルの可能性の中から、有用なものを選び出すことができる
  • モデルと設計との対応関係をシンプルに(1対1に)

    • 仕様変更が容易になる
    • コードはモデルの1表現になる

      • したがって、コードの変更はモデルの変更を意味する

        • 自然に実装できるようにモデルを変える
        • 実装を通じてドメインについて深い理解が得られたら、モデルに盛り込む
      • モデルの変更はプロジェクトすべてに波及する(=同期がとれる)
  • 単一モデルは誤解を減らす

    • モデルに基づいた設計やコードは、モデルと同様のコミュニケーション能を持つようになる
  • 言うは易く行うは難し

Modeling Paradigms and Tool Support

  • 実装をモデルに従わせるには、言語のパラダイムのサポートも重要

    • OOPとか
  • OOパラダイムは、モデルを設計・実装にそのまま落とし込める
  • 論理型パラダイムもモデル駆動設計にフィットする

    • Prologとか
  • Cのような、純粋な手続き型パラダイムは完全にはフィットしない

    • 複雑なデータ型は定義できるが、振る舞いまでは表現できない
    • ドメイン自体が数学的領域だったら例外的にフィットするが…

      • FORTRANなんかがそう
  • 本書では、OOPを扱う

From Procedural to Model-Driven

  • PCBの例再び

    • コンポーネントを結ぶnetをまとめた、busという概念がほしくなった
    • 回路のレイアウトを考える上で必要に

A Mechanistic Design

  • モデルにbusを導入せず、手続的なスクリプトで頑張っちゃったケース
  • やりたいことは「netをまとめてbusをなし、共通のlayout ruleを適用すること」
  • なのに、ちょっと違うだけの似たようなスクリプトが何ダースも生み出されてしまった

A Model-Driven Design

  • OOPで抽象化したケース
  • 拡張・変更が容易に
  • Service,Repository,Factory等を分割したことで、単体テストもできるように
  • 一度にこういう設計ができるものではない。イテレーションの中で優れたモデルに洗練していく

Letting the Bones Show: Why Models Mater to Users

  • ユーザにとってのモデルと、設計・実装側のモデルが乖離しているのは駄目だよね、という話

    • 昔のIEの「お気に入り」機能

      • ユーザーは「お気に入り」の名前を「ブクマしておきたいWebページにつけた名前」ととらえる
      • 実装的には、「URLが格納されたファイルの名前」が表示されている
      • したがって、「お気に入り」の名前には、ファイル名に使える文字しか含められない

        • 破ると、「A filename cannot contain any of the following characters …」と出る

          • ユーザからしてみたら意味不明。
            「ファイル名って何だ??」
        • デフォルトの名前で「お気に入り」を登録すると、使えない文字は暗黙に切り落とされる

          • 本機能では大した問題ではない
          • が、たいていのアプリケーションでは許されない
  • ユーザ向けのモデルを新たに作るのは混乱のもとだからよくない

    • 先の例では、「URLが格納されたファイルの名前」であることを隠し、
      「Webページにつけた名前」と思わせている
    • 「ファイル名」であることを明示して混乱を排除すべき

      • ユーザにもメリットがある

        • お気に入りファイルをexplorerで直接いじれる
      • 「良い」と思っているモデルで開発しているなら、ユーザ向けモデルを改めて作る必要はない
    • あるいは、データの管理方法を変えるべき

      • ファイルシステムに依存しなくする
      • 真に「Webページに名前をつける」ことができるようになる
  • ユーザやドメイン専門家の関心事をモデルに反映し、モデルの骨子をユーザに開示する

    • ソフトウェアの潜在的な機能を利用可能になる

      • 先の例でいうと、「お気に入りファイルをexplorerで直接いじれる」
    • ユーザにとって直感的な動作になる

HANDS-ON MODELLERS

  • 「実装にも関わるモデラー」
  • チームのメンバーの責務を縦割りにしすぎると、モデル駆動設計の妨げになる

    • プログラマが、「コードを変えることはモデルを変えること」と認識していない

      • この状態でリファクタしても、モデルは弱まるばかり

        • 【補】モデルとしての一貫性が損なわれるということか
    • モデルを作る人は、実装上の制約についてのカンを失う

      • 結果、設計・開発上役に立たない、浮世離れしたモデルが出来上がる
    • 実装者は、熟練した設計者から知識やスキルを得られなくなる
  • 役割特化するな、というわけではない

    • モデリングと実装とを完全分離するな、と言っている
  • 実装者はモデラーである

    • コードに変更を加えること、これすなわちモデルの変更である
  • モデル構築に関わっている人はコードに触れよ
  • コードを触る人は、コードでモデルを表現することを学べ
  • モデルの議論に大なり小なり関わる人は、ドメイン専門家と接触しろ
  • モデルについての考えをやりとりする場合は、実装者を巻き込んでユビキタス言語で

さいごに

  • 技術力の高い人たちを活かす方法は4部「Strategic Design」にて
  • モデル駆動設計は、詳細設計の影響を強く受ける。次節以降はこのことを扱う

英語

  • intricate

    • Very complicated or detailed.
  • accurete

    • Grow by accumulation or coalescence.
  • eerie

    • Strange and frightening.
  • call for

    • Make necessary.
  • lavish something on

    • Bestow something in generous or extravagant quantities on.
  • bestow

    • Confer or present (an honour, right, or gift)
  • confer

    • [with object] Grant (a title, degree, benefit, or right)
  • generous

    • Showing a readiness to give more of something, especially money, than is strictly necessary or expected.
  • extravagant

    • Lacking restraint in spending money or using resources.
  • reassure

    • Say or do something to remove the doubts or fears of (someone)
  • muddy the waters

    • Make an issue or situation more confused or complicated.
  • dichotomy

    • [usually in singular] A division or contrast between two things that are or are represented as being opposed or entirely different.
  • clumsy

    • Awkward in movement or in handling things.
  • eschew

    • Deliberately avoid using; abstain from.
  • imperative

    • An essential or urgent thing.
  • ripple

    • (of water) form or flow with a series of small waves on the surface.
  • slavishly

    • In a servile or submissive manner.

      • slaveからの派生
  • servile

    • Having or showing an excessive willingness to serve or please others.

      • serveからの派生
  • submissive

    • Ready to conform to the authority or will of others; meekly obedient or passive.
  • communicativeness

    • The quality of being willing, eager, or able to talk or impart information.
  • excel

    • Be exceptionally good at or proficient in an activity or subject.
  • lend itself to something

    • to be suitable for something
  • every inch

    • The whole surface, distance, or area.
    • 隅から隅まで
  • infer

    • Deduce or conclude (something) from evidence and reasoning rather than from explicit statements.
  • accommodate

    • (of a building or other area) provide lodging or sufficient space for.
    • 本文では「含めてる」くらいの意味
  • incisive

    • (of a person or mental process) intelligently analytical and clear-thinking.
  • benign

    • not malignant.
  • malignant

    • Evil in nature or effect; malevolent.
  • adorn

    • Make more beautiful or attractive.
  • interfere with

    • Prevent (a process or activity) from continuing or being carried out properly.
  • throw the baby out with the bath water

    • to lose valuable ideas or things in your attempt to get rid of what is not wanted
  • saddled

    • [usually be saddled with] Burden (someone) with an onerous responsibility or task.
  • onerous

    • (of a task or responsibility) involving a great deal of effort, trouble, or difficulty.
  • dictate (noun)

    • An order or principle that must be obeyed.
  • ivory tower

    • If you describe someone as living in an ivory tower, you mean that they have no knowledge or experience of the practical problems of everyday life.