DDD Alliance! ドメイン駆動設計のためのオブジェクト指向入門

提供: IT勉強会・セミナーまとめWiki
移動: 案内検索
開催日 2016/1/21
開催情報
タグ DDD, オブジェクト指向
登壇者 増田亨さん
セッション資料
セッション動画
    ブログなど


    ※以降「ドメイン駆動設計」を「DDD」、「エリック・エヴァンスのドメイン駆動設計」の書籍を「DDD本」、オブジェクト指向設計を「OOD」と略します。

    基礎知識

    DDD

    • ドメイン層のソフトウェア設計
    • ベースはOOD
    • ドメインを分析する人がコードを書く
      • ドメインを分析することでクラスを発見できる
      • ドメインの分析者と実装者が分かれるのは、アンチパターン
      • ウォーターフォールでも、保守フェーズでは実装者が分析をやるのだから、プロジェクトの最初からそれをやればいい
    • ドメインを学び学んだことをコードで表現する
    • ドメイン層のオブジェクト
      • Plain Old Java Object(Not Java Beans)
      • 業務の関心事の表現
      • 業務的な観点で(コンピューターの観点を隠蔽して)判断、計算、加工をする。
      • 基本データ型は返さない

    OOD

    コードの整理

    • クラス単位に関連するコードを整理する
    • 変更があちこちに飛び火しない
      • データクラスと機能クラスを分けるのは、アンチパターン
    • 変更した箇所のテストOKなら全体もOK
      • OODでやれば、これが自動的に実現できるわけではない。
    • 判断、計算、加工のロジックを集約する
      • しっかりクラスを実装すれば、変更時に、一か所を読み、一か所を変更し、一か所をテストするだけで済むようになる。

    ドメイン層の構造

    • Aggregateが分析、設計、実装の単位

    アーキテクチャ

    • 構造
      • 強く関連する部品は集約する(アグリゲート)
      • アグリゲート同士は、分離性を高め、必要最小限につなげる

    オブジェクトの設計

    独自の型を設計する

    • ドメイン層は「独自の型」だらけにする
      • 「独自の型」は利用者の関心事
      • 基本データ型はコンピュータの関心事
    • オブジェクトのコラボレーションの設計
      • オブジェクトとオブジェクトが協力して仕事をする

    コラボレーションの設計原則

    • 契約による設計
      • お互いが対等の立場
      • 相手を詳しく知りたがってはいけない
      • OODのベースになる考え方
      • Assert構文を使うことが契約による設計ではない
      • DDDをやるなら、ビジネス上の「契約」について勉強しよう
        • 契約による設計についての理解が深まり、ドメイン上の契約についての理解も深まる

    実現手段(how)を隠蔽する

    • コンピューターの関心事を隠蔽する
      • 基本データ型
      • JavaのAPI
    • ドメインオブジェクトのPublicメソッドは業務の関心事。引数や戻り値に、基本データ型が出てきてはいけない

    事例「転職サービス」

    • DDDのEntityとは一般的に使われるEntityとは意味が違う
      • 「参照オブジェクト」と呼ぶ方がふさわしい
      • 顧客の関心事への参照点
      • 顧客との会話の語彙の起点
    • 値オブジェクト
      • 業務の関心事の基本語彙
      • 目的に特化して制約をかける
        • 制約による「安定」

    Q&A

    • 参照系の話が多かったが、更新系でトランザクションはどう扱っているか?
      • どちらかと言えば、アンチトランザクション派。細かい単位でレコードを登録している。大きな単位で一気に書き込まなければいけないというのは技術者の先入観では?
    • ドキュメントは?
      • 書かないわけではない。例えば権限設定のマトリックスなどは書く。ただメンテナンスはしない。
    • あるEntityの保持する値オブジェクトだけ返す実装についてはどう思うか?
      • 業務上の関心事で必要なら、そういうこともある
    • クラスのコンストラクタが丸見えなのはどう思うか?
      • Factoryなどを使って、隠した方がよいこともある
    • 要件の分析について
      • 開発者はその事業を切り開いていくくらいの覚悟でやっていく。それも含めて開発者のロール。マイナンバーのシステムを例にとれば、どうあるべきかを考えるところからやる。
    • 「生年月日を入力してください」という旨のメッセージを保持しているドメインオブジェクトがスライドに出てきたが、ユーザーに見せるメッセージは、プレゼンテーションレイヤに属するものだと思うので、ドメインオブジェクトがメッセージを保持していることに疑問を感じた。フレームワークの都合や開発効率の向上などの理由で、あえてそうしているのでしょうか?
      • ドメイン層に書いたほうが、ルールに変更があった時に、変更が楽で安全になると考えて、積極的に意識的にそうしている。フレームワークに妥協した意識はない。

    参考書籍

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

    エリック・エヴァンス 翔泳社 2011-04-09
    売り上げランキング : 125643
    by ヨメレバ
    新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

    Martin Fowler オーム社 2014-07-26
    売り上げランキング : 4069
    by ヨメレバ
    実装パターン

    ケント・ベック,Kent Beck ピアソンエデュケーション 2008-12-22
    売り上げランキング : 61959
    by ヨメレバ
    オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

    バートランド・メイヤー 翔泳社 2007-01-10
    売り上げランキング : 113854
    by ヨメレバ
    オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング)

    バートランド・メイヤー 翔泳社 2008-08-29
    売り上げランキング : 43668
    by ヨメレバ
    オブジェクト指向をきちんと使いたいあなたへ (Software Design別冊)

    Software Design編集部 技術評論社 2016-03-03
    売り上げランキング : 69842
    by ヨメレバ