poeaa ch8 Putting It All Together (1/2)

PoEAAデザインパターン勉強メモ

出典: 


Putting It All Together

  • これまでの総集編
  • あくまで、本書提示のパターンは読者の考えの一助にすぎない。
    読者の考えを置換するものではない

    • プロジェクトについては著者よりも読者のほうが詳しい
    • 相談を持ちかけられることがあるが、5分程度の説明で特別なアドバイスを送れようはずもない
  • (設計に関する)決断は、二度と変更できないわけではない

    • 例えばアーキテクチャレベルのリファクタリング

      • Transaction Script -> Domain Modelとか
    • 労力は計り知れないが不可能ではない
    • XPが嫌いでもこの3つはやれ

      • CI
      • TDD
      • Refactoring
    • 万能薬ではないが、あとで決断を変更しやすくなる

Starting with the Domain Layer

  • 選択肢

    • Transaction Script
    • Table Module
    • Domain Model
  • 選び方

    • ドメインの複雑性により選ぶ

      • どうやって定量化すんの(いやできない)
      • 定性的にも測りがたい
    • データソース層の実装の難しさ
  • Transaction Script

      • 一番単純
      • 手続型モデルにフィットする
      • システムトランザクションをわかりやすくカプセル化する
      • RDBの上(の層)に構築しやすい
      • ビジネスロジックが複雑だと破綻する

        • コード多重化
        • 単純な買い物アプリケーション程度ならぴったり

          • 値付けに特別なロジックがない
          • 商品カタログある
          • 買い物かごがある
          • 以上
        • それ以上複雑だと指数関数的にやばくなる
  • Domain Model

      • オブジェクト指向大好きおじさんは常にこれを選ぶ
      • 複雑なドメインロジックにはこれ一択
      • 慣れればシンプルなロジックでこれを使うのも苦ではなくなる
      • ドメインモデルの利用法の習得が難しい

        • スキルを要する
      • RDBコネクション

        • オブジェクトDBを使う者も

          • でも大抵選択肢にはならない

            • 主に非技術的な理由で
            • 【補】枯れてないから、とか?
        • オブジェクトモデルと関係モデルのミスマッチ
  • Table Module

    • 前者2つの中間
    • Transaction Scriptよりもドメインロジックをうまく取り扱える
    • Domain Modelほど複雑なドメインロジックは扱えない
    • が、RDBとよくフィットする
    • データソース層との兼ね合い

      • 例: .NETプラットフォーム
      • データソース層としてRecord Setが適する

        • ツールが充実している
      • この場合Table Moduleが適する
  • ツール(ミドルウェアとか)との兼ね合い

    • 理屈の上では、アーキテクチャありきでツールが選択されるべき
    • 現実、そうではない
    • ツールにアーキテクチャを合わせる
    • Table Module

      • .NETならこれが良い

        • 親和性の高いRecord Setを取り回す仕組みが組み込まれているから

Down to the Data Source Layer

  • ドメイン層の選択にもとづいて決める

Data Source for Transaction Script

  • Row Data Gateway

    • 1レコード1オブジェクト
    • オブジェクトはexplicitなインタフェースをもつ
    • 【補】メソッドとかが生えているということでしょう
  • Table Data Gateway

    • 1テーブル1オブジェクト
    • インタフェースはRow Data Gatewayに比べてimplicit

      • レコード集合の構造に依存
    • 【意訳】SQLをラップしただけな感じになる

      • 原文: little more than a glorified map
  • プラットフォームとの兼ね合い

    • Record Setありきで動くようなツールがあるケース

      • UIツール
      • transactional disconnected record sets
    • この場合Table Data Gateway
  • Transactional Scriptを選択した場合、ふつうO/Rマッピング不要

    • 【補】Transactional Scriptを選択したからには、ドメインロジックが単純なはず
    • ここにおいて、メモリ上のオブジェクトとRDB上のリレーションがきれいに対応する
    • ミスマッチがないので、わざわざマッパを用意する必要がない
  • 並列性の問題はまずない

    • scriptがビジネストランザクションに対応づいているため
    • スクリプト丸ごとシステムトランザクションで包める
    • 例外: 読み出し、編集、永続化が別れているケース

      • Optimistic Offline Lock使え

Data Source for Table Module

  • Table Moduleを選定したということは、プラットフォームがRecord Setをサポートするツールを提供しているはず
  • Table Data Gateway使え

    • Record SetとTable Data Gatewayとは神の思し召しかというくらいマッチする

      • 原文: made in heaven
  • Record Setが並列制御の仕組みを持っているとなおよい

    • Unit of Workを兼ねてくれる

      • Maintains a list of objects affected by a business transation
        and coordintates the writing out of changes
        and the resolution of concurrency problems.
    • 自前で並列制御しなくてすむので、髪の毛の減少を抑えられる

Data Source for Domain Model

  • Domain ModelはDBとのコネクションが複雑になる
  • Domain Modelの複雑性による分岐

    • Active Record

      • ロジックが単純ならこれ

        • DBと親しいのがたかだか数十クラス
      • DBアクセスを切り出すこともできる

        • Table Data Gateway
        • Row Data Gateway
      • が、大して変わりはない
    • Data Mapper

      • ロジックが複雑ならこれ
      • Domain Modelを可能な限り他層から切り離す人
      • 実装たいへん

        • 作るな
        • ツール使え
      • O/RをマップするならUnit of Workを強く推奨

        • 並列制御のキモ

The Presentation Layer

  • 下層の選択とは比較的独立している
  • クライアントどうする

    • Webブラウザ
    • rich-client

      • Webブラウザよりも良いUI

        • 【補】できることが多い、くらいの意味か
      • クライアントアプリケーションのデプロイが必要
    • 著者はWebブラウザ推し

      • rich-clientはプログラミングの手間が大きい
      • Webブラウザで実現できないならrich-client
  • 以下、Webブラウザ前提
  • MVC使え

    • Mの話は済んでいる(Domain Layer, Data Source Layer)
    • CとVをどうするか
  • ツールとの兼ね合い

    • Visual Studio

      • Page Controller/Template Viewが一番簡単
    • Java

      • フレームワーク使え

        • 書籍執筆当時はStrutsが人気
        • このフレームワークではFront Controller/Template View
  • 自由なら?

    • サイトがドキュメント指向(静的・動的ページを出し分けるようなやつ)なら

      • Page Controller

        • An object that handles a request for a specific page or action on a Web site.
        • input controllerの一つ
        • 【補】Laravelの「Controller」はこれ
      • 【補】比較的シンプルなサイト、という意味か
    • ナビゲーションとUIが複雑

      • Front Controllerも使うことになる

        • A controller that handles all requests for a Web site.
        • input controllerの一つ
        • リクエストの処理を共通化する人

          • セキュリティ
          • i18n
          • 特定のユーザの特別なビュー出す
        • 【補】route middleware的な感じ
      • 【補】Page Controllerが複雑になるので、共通処理を切り出したくなるということかな
  • ビューの選択

    • 執筆当時、Template Viewが優勢
    • 著者はTransform View推し

      • テスタビリティ高い

        • 【補】関数的にXML等を加工していくからかな
    • ルック・フィールの異なる複数のビューが必要ならTwo Step View

      • 【補】共通の論理ビューを出してから、2段目でルック・フィールを適用してレンダリング
  • 下層との連絡

    • 可能な限り同一プロセス内であることが望ましい

      • はやい
    • プロセス間通信やリモートプロシージャコールは遅い
    • やむを得ず行うなら、遅い通信の回数を少なくする工夫をする

      • ドメイン層にRemote Facadeを立てる

        • 【補】coarse-grainedなインタフェースを提供するFacade
      • Data Transfer Objectで、伝送するオブジェクトをまとめる

英語

  • pundit

    • An expert in a particular subject or field who is frequently called upon to give their opinions to the public.
  • prod

    • Stimulate or persuade (someone who is reluctant or slow) to do something. ‘they attempted to prod the central bank into cutting interest rates’ More example sentences
  • panacea

    • A solution or remedy for all difficulties or diseases.
    • 万能薬
  • fill the bill

    • ぴったり要求にかなう
  • look down one’s nose

    • 見下した態度を取る
  • zealot

    • A person who is fanatical and uncompromising in pursuit of their religious, political, or other ideals.
  • fanatical

    • Filled with excessive and single-minded zeal.
  • finesse

    • [mass noun] Impressive delicacy and skill.
    • [with object] Bring about or deal with (something) by using great delicacy and skill.
  • inexorably

    • In a way that is impossible to stop or prevent.
  • focal

    • Relating to the centre or most important part.