PHP Mentors

10月5日(土)にLearning Community Factory主催で開催された「オブジェクト設計エクササイズ -チームモデリングで学ぶドメイン駆動設計-」に参加しました。

• オブジェクト設計エクササイズ -チームモデリングで学ぶドメイン駆動設計-

講師は増田亨さん(@masuda220)です。これまでに第1回(オブジェクト設計エクササイズ -コードで覚えるオブジェクト設計-)、第2回(オブジェクト設計エクササイズ -モデルとコードで学ぶ責任駆動設計-)と開催されたオブジェクト設計エクササイズシリーズの3回目ということでした。私はこの回が初めての参加でした。

内容と感想

最初に増田さんからドメイン駆動設計についての基本的な考え方を簡単に説明いただいた後、モデリングのお題が発表され、そのお題のドメインモデリングを行うといったものでした。4名〜6名、ほぼその場で初めて出会う人がチームになって、おそらく普段の業務とは違うドメインのモデルを話し合って作っていくのですが、メンバーのバックグラウンドもバラバラ、ドメイン駆動設計についての理解もバラバラです。このようなチームメンバーでドメインモデリングができるのでしょうか？

お題は「ホテルの料金プランを見て、ドメインモデリングせよ」というもので、ズバリ「ホテル千畳敷」さんの料金プランページが渡されました。アプリケーション要件は固定されたものがあるわけではなく、いろいろなアプリケーションに使えるドメインモデルを作れ、という指示でした。この指示について、私は良いなと感じましたが実際にチームでは多少の混乱があったのも事実です。というのも、「アプリケーションを想定してはいけない(ユースケースを考えてはいけない)」と受け取ったメンバーがいたためです。ドメインモデルはアプリケーションから独立した、1段抽象レベルの高いものとして作るための指示であって、実際にモデリングするには具体的なアプリケーションとまではいかなくても、何らかのユースケースは想定しないとモデリングが深まりません。私が参加したチームでは最終的には、予約をしたい場合の料金を計算できることを目標にすえることで、モデリングを進めることができました。

参考になったこと

• 早い段階で「モデルを説明する」
  DDDではユビキタス言語を使ってシナリオを上手く言葉にできるかどうかが重要で、これによってユビキタス言語から漏れている概念がないか、検証することができます。この時点で、モデルにあらわれていない言葉が口頭説明で補足されていたりするのは、概念が抽出できていない証拠ということでした。
• 「コーディングできるモデルか」を基準にする
  これも、メンバーの受け取り方をコントロールする必要がある（メンバーによってはデータベースのことなどに意識がいってしまう）と感じましたが、オブジェクト指向／DDDとしてはやはり重要な観点だと思いました。コードに落としこむイメージを持たずにモデリング／設計だけを進めるのはほぼタブーで、常に（ドメインレイヤーの）コードとリンクさせる意識を持っておくことは、あるべきモデルに向かうための近道でもあると感じました。
• 「業務の価値を概念化する」
  今回のホテルの料金プランをチームでモデリングした成果として、1年の中のある期間を「繁忙期」それ以外を「通常期」という言葉を選択していました。これに対する増田さんからのフィードバックで、概念が言語化されたことは良いことだと評価頂きましたが、もう一歩踏み込んで、「稼ぎどき」と「閑散期」と言うこともできるという指摘を頂きました。これはどういうことかについて私なりの理解では、「繁忙期」「通常期」という2つの言葉では重み付けが等しいか、もしくはどちらかと言うと「繁忙期」は忙しくてマイナスなイメージも（言葉そのものからは）抱くかもしれません。一方「通常期」には何ら特別なイメージがありません。これを「稼ぎどき」「閑散期」と言い換えると、稼ぎどきには稼ぎどきのやり方、料金設定がある、「閑散期」にはまた別の戦略で稼働率を上げるといった考え方に素直につながっていきます。こういった適切な言葉の発見、そのドメインのビジネス的な価値が反映された言葉の発見によって、モデルが活き活きとするのだということを痛感しました。

おそらくチームメンバー同士が知り合いではなく、力量はたとえバラバラであっても対等な関係だったからこそ、モデリングに無駄な前提が入り込まず、メンバー間の認識を探りあいながら素直にモデリングに集中できたと感じました。こういったニュートラルなチームでのワークショップに参加するという機会は持とうとしてもなかなか持てるものではないと思います。とても新鮮で貴重な体験でした。同じようなワークショップがまたあれば、今後は積極的に参加していきたいと思います。

参考リンク

• 私たちPHPメンターズもDDDについての講演やワークショップを行っています。PHPカンファレンスで行ったDDDワークショップのスライド
• 本ブログのDDDタグ記事一覧

Symfony Advent Calendar JP 2012 - Day 3

ドメイン駆動設計にしたがってドメインモデルをソフトウェアとして表現するのにエンティティが使われます。エンティティは、ドメイン駆動設計におけるモデル駆動設計パターンの1つに分類されます。

賢すぎるエンティティはアンチパターン

Ruby on Rails由来のアクティブレコードと直結したMVCフレームワークでは、本来エンティティとして扱われるべきクラスを「モデルクラス」と呼び、そこにビジネスロジック等を実装することが推奨されていました。これらのフレームワークでは、自らモデルレイヤー部分もカバーしておきながら、すべてをエンティティとして実装することを強いるため、ドメインモデルの実装にはほとんど自由度がありませんでした。

このスタイルに慣れてしまうと、ピュアなクラスでドメインレイヤーを実装できる状況においても、誤った設計に陥ってしまいます。

問題

• 責務が多すぎることにより、依存関係が複雑になる
• レイヤーの境界があいまいになりやすい
• 実装時の明確な指針がないため、知識の分散が生じやすい

解決

ドメインモデルを分析・設計する時に使える手法として「責務駆動設計」があります。責務駆動設計とは、「オブジェクトデザイン（Object Design: Roles, Responsibilities, and Collaborations)」等で紹介されているオブジェクト指向による分析・モデリング手法です。オブジェクトデザインでは、分析によって現れたクラスを責務に分割していく時に6つの「ロールステレオタイプ」を用います。

• 情報保持役(Information Holder)
• 構造化役(Structurer)
• サービス提供役(Service Provider)
• 制御役(Controller)
• 調整役(Coordinator)
• インターフェース役(Interfacer)

エンティティは本来「情報保持役」であり、オブジェクト指向のクラス設計原則（SOLID）に従えば、これ以外の責務を持つべきではありません。（注意深く設計する場合、1つのオブジェクトに複数の責務を割り当てることもできます。） 明らかなことは、何でもかんでもエンティティに詰め込んで賢くするのではなく、責務を見分けて適度に分割すべきということです。

ドメイン駆動設計のパターン（エンティティ、値オブジェクト、リポジトリ、サービス、ファクトリ）やオブジェクトデザインの6つのロールステレオタイプなどを設計の型として用いることで、「良い設計、良いソフトウェア」を実現しやすくなるといえるでしょう。

最後に、オブジェクト広場にて2008年に掲載されたオブジェクトデザインの著者Rebecca Wirfs-Brockさんへのインタビューで「良い設計」について話された部分を引用します。

「良い設計」とは何なのでしょうか？たとえば、質であったり、構造の美しさであったりするのでしょうか？

これは面白いところですね。「良い設計」は「十分に良い設計」と異なります。Scott Ambler さんなどは、 just barely good enough modeling (*5) を提唱していますが、私は「十分良い設計」は実のところ十分ではないと思っています。 シンプルなものの中には、シンプル「過ぎる」ものもあります。問題が複雑である場合、その解決策も複雑になりがちです。その際は、コードも分かりやすいものになるとは限りません。複雑であり、シンプルにできないためです。理解できるものである必要はありますね。

「良い設計」とは、将来起こりえると思うことや、減らしたいリスクを考慮しているものです。また、結果としての実装が、安心して使えるものであり、メンテナンスしやすいものである必要もあります。

また、設計は変更に耐えるものでなければなりません。設計に何一つ追加できないのは良くないですよね。 将来起こりえると思うことを考慮した、分かりやすさに関する適切なバランスが必要ですね。また、2 年前には良かったものでも、5 年後にはよくないものになる場合もあります。その場合は、新しく作り直したり、考え直したりする必要があります。

参考

• オブジェクトの広場： Rebecca Wirfs-Brockさんインタビュー( 前編 )

技術評論社WEB+DB PRESSのPHP連載「巨人の肩からPHP - 先人たちに学ぶモダンプログラミング」の連載第2回「Phake、Mockeryによるオブジェクト指向プログラミング」を収録したvol.70が先日発売されました。

• WEB+DB PRESS Vol.70｜gihyo.jp … 技術評論社

この連載では、PHPという言語に限定しない、ソフトウェア開発分野で汎用的、かつ今後も長く通用する知見をとりあげ、PHPで実際に利用するためのライブラリなどを紹介しています。第2回ではモックフレームワークであるPhakeとMockeryを取り上げています。モックフレームワークをテストのための道具という位置づけではなく、システムの中のオブジェクト同士のコラボレーションを表現するツールと捉え、オブジェクトの責務をテストコードに表現する過程などをコードとともに解説しています。

• mlively/Phake
• padraic/mockery

今回の記事で紹介している「Growing Object-Oriented Software, Guided by Tests」は、日本語の訳書の出版も間近とのことです。WEB+DB PRESSをお読みになった後、詳細を学びたい方は是非手にとって頂くことをおすすめします。記事で紹介した他の書籍も合わせてリストアップしておきます。