#eric.evans

2015年10月03日にPHPカンファレンス2015内で、ミニカンファレンスとして開催されたPHPメンターズセミナー「モデルを設計せよ！―ドメイン駆動設計を超えて」に参加してきました。

モデルを設計せよ！―ドメイン駆動設計を超えて

視点

PHPメンターズ 後藤秀宣 @hidenorigoto

セッションのテーマは「視点」。いくつかの実例から、参加者が視点そのものについて実際に考えることができる体験的な講演でした。後藤さんのスライドに関しては公開は無しとのことです。このセミナーでは、この「視点」という言葉が全体を通じてのテーマになっていると思います。

特に印象深いのが「コップを空にする」話です。既にたくさんの知識を身につけた修行僧が、高名な僧侶のもとに学びに行きます。修行僧がひとしきり知識を披露した後、高名な僧侶は空の茶碗にお茶をそそぎ、そそぎ続けて、茶碗からお茶が溢れてしまってもそれをとめません。

高名な僧侶は修行僧に、身につけたあふれんばかりの知識を脇において、頭のなかをいったん空にして、新しい知識を吸収する大切さを教えたかったのです。後藤さんは、いったんこれまで積み上げた知識は飲み干して、そこにこのセミナーで得られる知識をたくさん注いで帰ってもらいたいと話されていました。

フォーム検討に対する概念フォーム理論からのアプローチ

名古屋経済大学 経営学部教授 中西昌武

フォームというのは帳票（Webシステム等では画面）のことです。リレーショナルデータベースモデルにはコッド博士による理論化・体系化がなされているのに、フォームの構造に関してはそれに相当する数学的基礎がない。ならばその理論を作ってしまおうということでフォーム構造の数学的な基礎を構築されています。

帳票の裏にある論理テーブルの構造をノードとパスとみなして、その繋がり方とアクセスするための経路（これがフォームの構造として表現される）を行列として定式化できます。これにより、グラフ理論を用いて生成可能なフォームパターンを網羅的に示すことができるというような理論でした。

確かにフォームをどのように構成するかなどは、実業務の中でも経験によって作っている部分もかなりあると思うのですが、それがちゃんと数学的に定式化できて、パターンを数え上げることもできるとしたら、例えばユーザはフォームの選択肢の中から特定のフォームパターンを選んで、あとは自動的に画面が生成されるということも可能になってきます。

また、フォームを選びとるということは、背後にある論理データモデルに対するどういう見方を選びとるかということであって、その選択したものが、ちゃんと論理的に妥当なことが数学的に保証されている、ということは非常に重要なことだと感じました。

中西先生は、以前にIT勉強宴会で講演されていて、その時のレポート記事の方も参考にして下さい。

ジェネレーティブ・プログラミングの世界 | ＩＴ勉強宴会blog

PHPメンターズ -> 第29回 IT勉強宴会in名古屋「ジェネレーティブ・プログラミングの世界」参加レポート

興味を持たれた方は中西先生のこれまでの論文・論考も是非ご覧ください。現在、中西先生は情報システム学会で「超上流工程における要求分析への科学的アプローチ」研究会を開催されています。研究会への参加をご希望の方は第３回勉強会のご案内をご覧ください。

ドメイン駆動設計 ～ユーザー、モデル、エンジニアの新たな関係～

株式会社フュージョンズ 杉本啓 @sugimoto_kei

ドメイン駆動設計 ～ユーザー、モデル、エンジニアの新たな関係～ from 啓 杉本

ドメイン駆動設計に対する見方をいくつかの視点の切り替えで明快に整理した名演だったと思います。

エリック・エヴァンスのDDD本は示唆深く、ドメインモデルの設計に関して深い洞察を得られる本だと思うのですが、読み解くのがとても難しい本だとも思っています。杉本さんの講演（資料）を横においてエバンスのDDDを読みなおしてみるとまた新たな発見があるかもしれません。

一つ目の視点の切り替えは、ドメインモデル自体が存在する領域をどこに置くかということです。ドメインのモデルですから、字義通りに捉えるとドメイン領域に関するモデルと考えてしまいそうです。

しかし杉本さんは、ソースコード管理システム（GitとSubversion）の例を用いて、例えばコミットという概念はドメインの領域にではなくむしろ具体的なツールの側のソリューションから現れてくる概念だと説明します。そこから、ドメインモデルはドメイン（問題領域）の側から自然に立ち現われてくる（見つけだすとでも言ったらいいのでしょうか）ものではなく、むしろソリューションの中から我々が意図的に設計しようとするところから現れる解決領域のためのモデルとして捉えます。

DDD本の中で船舶/コンテナが出てくる海運事業モデルの中で、船荷証券（B/L）というモデルを見出す場面がありますが、これはモデルの問題領域を深く考察することで得られるものではなく、貿易実務の中で伝統的に開発されて普及してきた情報処理に関する事務処理パターン（船荷証券は法制度化もされています）、つまり管理過程に着目することで当然のように出てくるモデルということになります。

似たような問題領域と情報処理モデルの関係には、会計分野における複式簿記、鉄道業務におけるダイヤグラムなどがあります。

ドメインモデルは、解決領域のモデルであるというのが杉本さんの指摘だと思います。

（船荷証券に関する議論は本ブログの記事PHPメンターズ -> Practical DDD #3: モデルの深さで詳しく議論されています。）

二つ目の視点の切り替えは、このようにドメインモデルを眺める視点を移すことが、分析と設計の線引きを変えることにつながるという点です。これにより ドメイン駆動設計を、1.エンジニアリング の対象を広げながら、2.その広がったエンジニアリング活動内部での分裂を防ぐ、つまりソリューションのために作り出されたモデルと実装モデルの乖離を防ぐものだと捉えることができるようになります。

このように整理すると、各種の分析手法―分析モデルから設計モデルに落としこむ一般的なオブジェクト指向分析や、管理過程に着目して情報の流れや帳簿組織を表すデータモデルを構築する現代的なデータ指向分析と構造を比較できて面白かったです。

そして三つ目の視点の切り替えは、エバンスのDDD本の構成に関するものです。確かにエバンスのDDD本を頭から読んでいると、第2部においていきなり実装寄りの個別の実装パターンに入るようでおやっと思ってしまいます。

あるいは、実装者の立場からすると馴染みのある用語や実践しやすいプログラムの構成要素が出てきて、思わず飛びつきそうになります。プログラムの中にエンティティやリポジトリを登場させることがドメイン駆動設計だと間違った解釈をしてしまう場合もあるかもしれません。

この点に関して、杉本さんは、DDD本を構成するパターンランゲージを「原則のレイヤ」と「実践のレイヤ」にわけ、前者をオブジェクト指向に依存しない普遍的な部分、後者をオブジェクト指向でドメイン駆動設計を実践するためのパターン群とみることを提案しました。

そして、前者は原則的なものなので、オブジェクト指向だけではなく、データ指向分析などの様々なパラダイムの実践手法に適用することが可能になると説明します。

このような3つの視点の切り替えを通して、エバンスのDDD本を読み直すと他にも色々な発見がありそうなので、近いうちに一通り読み直してみたいと思います。

Frameworks We Live By: Design by day-to-day framework development: Multi-paradigm design in practice

PHPメンターズ 久保敦啓 @iteman

Frameworks We Live By: Design by day-to-day framework development: Multi-paradigm design in practice from Atsuhiro Kubo

James O. Coplienのマルチパラダイムデザインは1998年に最初の版が上梓された本なので、実はエリック・エヴァンスのドメイン駆動設計よりも先発の書籍になります。

にも関わらず、問題ドメインの概念に根ざした分析/設計/実装における単一のモデルの構築を目指すという目標は同じでありながら、そこに至るための方法論に関してはCopeのマルチパラダイムデザインの方がエヴァンスのドメイン駆動設計にはなかった設計手法を明示している、というのが久保さんの主張です。

マルチパラダイムデザインでは、人間が物事を認識するときの認知モデルに基づいて問題ドメインを分析していきます。久保さんの発表で出てくる、古典的カテゴリー理論と新しいカテゴリー理論の違いは、物事を生得的で客観的な事象として捉えようとするのか、経験に基づいた具体的・身体的な認知からの拡張によって得られるものなのかという違いだと思います。

Copeはここでいう認知に関しては後者の見方を基礎にしていて、問題ドメイン分析においてそういった認知機構を元に問題をサブドメインに分割して、そうして得た対象に対して、共通性分析、可変性分析を進めていきます。ここで重視されるのはやはり「審美眼、洞察、経験」によるものであって、例えば「よく知られたサブドメインは設計の優れたスタートポイント」などを考えるとよくわかります。

そのうえで、解決ドメイン分析、ドメインモデル設計（変換分析）に移るわけですが、ここでは問題ドメインの構造と解決ドメインの構造のマッピングをしながら分析していきます。そして解決ドメインの構造で問題ドメインの構造を再定義していきます。これは、何度か繰り返されるプロセスになります。つまり、解決ドメインが提供する抽象(構造)－型、クラス、継承、リレーション、エンティティ、値、パターンといった一群の文法要素やイディオム－が問題ドメインを洗練していくのです。すなわち、解決ドメインに対して利用することのできるパラダイムを用いて問題ドメインを再構築していくのです。

これは、先ほどの杉本さんの解決領域のためのドメインモデルにも繋がっていて、マルチパラダイムデザインのドメインモデル設計（変換分析）で再定義、洗練されたドメインモデルは、エリック・エヴァンスのDDDが目指している単一のモデルと等価なものになります。

これらのマルチパラダイムデザインの議論から久保さんは一歩進んで、問題分析で目の前にあるニーズを解決する特定の分析から得られる知見よりももっと広い視野で対象とするドメインのフレームワークを作るという視点を持ち込むことで、幅広い領域に適用できる共通性を発見することが出来るといいます。

ここで言うフレームワークは一般的に知られる、SymfonyやRuby on RailsのようなWebアプリケーションフレームワークだけではなく（もちろん、それらもある特定のドメインを対象としたフレームワークです）、様々な問題領域のドメインに対して適用されるフレームワークのことを指しているのだと思います。

例えば、発表の中であったワークフローエンジンもそうですし、ルールエンジン的なものや、もっとアプリ特有のドメイン用途のフレームワークも考えていいと思います。

それらのフレームワーク開発を通してドメインについて日常的に考え指向することで、プログラマー自身が設計者となって、実装の中でドメインモデルを洗練させていくモデラーとなるというのが久保さんから一番大きく受け取ったメッセージです。最後の「Code the Domain! You are a Domain Coder!」、ドメインをコードにせよ、あなたがドメインコーダーなのだという言葉は、ドメイン駆動設計を超えて、さらにマルチパラダイムデザインを超えて、その先にあるものとしてとても希望の持てるものだと思いました。

Coding We Live By ～モデルと実装の今と未来～

PHPメンターズ 後藤秀宣 @hidenorigoto

この講演で後藤さんは、久保さんまでの講演で辿り着いたドメインモデルを設計しながら実装する、実装しながら設計するということを、もう一度興味深い実例を示して強調します。

これは、後藤さんが実際に取り組んだアプリケーションなのですが、幾つかのリストを組合せてデータを生成する機能が既存機能としてありました。それは、元ネタのリストからいったん全パターンを組み上げて「分割」するという構造になっていたそうです。業務側の人もその機能のことを「分割」と呼んでいました。それ自体はとても自然な設計で作りも悪くはなかったのですが、多数の機能追加や変更の結果、プログラムの変更がとても大変な状況になっていたようです。そこで、後藤さんが入った時に、それまでの他のアプリケーションでの経験から「部分集合を作る」「集合の直積を作る」ということとその集合演算で処理を表現できることに気付いて、実際にその演算をするためのライブラリを実装しました。そして、その集合演算をサブドメインとして切り出すことで、処理を簡素化するとともに変更に対して柔軟に対応することができるようになったということです。

このような実践を行うためには２つの条件、すなわち、既に後藤さんの頭のなかのツール箱にそういう解法に対するアイデアがあったことと、後藤さん自身がそのアイデアを実装してそれが有効であることを証明することができたということが重要であったと思います。

セミナー全体を通して「視点」の切り替えが新しい気づきや理解を促してくれて、ドメイン駆動設計を横糸に、ドメインとコードというものが強く結びついて、実装者がドメインモデラーなのだという主張をはっきりと感じ取れるようになりました。

後藤さんは「視点」の重要性を示し、中西先生は、フォーム構造という要求分析の要素にある視点（フォームを選びとるということ）から導き出される構造の数学的理論的な土台を与えてくれました。杉本さんは、ドメイン駆動設計を題材にとり、今までとは違った視点でそれを解釈し直すことで、ドメイン駆動設計をより納得行くかたちで再定義してくれました。久保さんは、そのドメイン駆動設計の先にあるマルチパラダイムデザインによる設計からさらにフレームワークによる設計への道筋を、自らの経験と成果から、これも視点を変えて設計活動を捉え直すことで、示してくれました。また、フレームワークと捉え直したドメインの設計活動の中で、実装の中でドメインモデルを設計する、実装という活動そのものが設計なのだというメッセージを提示してくれます。

そして、最後に「ドメインモデルを設計しながら実装する、ドメインモデルを実装しながら設計する」という後藤さんの言葉でセミナーは結ばれました。

セミナー全体の感想

久保さんのセッションや質疑応答の中で、ドメインエキスパートと並立する存在としてのドメインモデラーという言葉がでたのですが、ドメインモデラーは、杉本さんの言葉で言えば解決領域（情報管理過程）の専門家としてドメインエキスパートと協同してドメインモデルを作っていきます。

そのためには、特定の領域の情報管理過程、情報モデルについて精通している必要があります。みなさんも、実装者であれば何らかの分野（業務モデルとも限りません、それはソーシャルゲームの場合もあるでしょうし、組み込み領域のプログラムの場合もあると思います）についての情報モデルの専門家であることが多いと思います。その解決領域に関する知見を深めて、道具箱に使えるツールを増やしておけば、それを実装の現場で応用することが出来る場面も増えるのではないかと思いました。

当日、その後の関連ツイートについて