去る10月3日（土）、「PHPカンファレンス2015」に併設開催の「PHPメンターズセミナー」に参加してきました。
「PHP」関連のカンファレンスではあるのですが、メンターズセミナーの副題は「モデルを設計せよ！－ドメイン駆動設計を超えて」です。しかもツイッターで偶然にお見かけして以来注目している杉本氏（@sugimoto_kei）や久保氏（@iteman）が登壇するではないですか。これは行くしかない！
「PHPメンターズ」のブログには、当日のレポートが掲載されています。
「PHPカンファレス2015 PHPメンターズセミナー「モデルを設計せよ！―ドメイン駆動設計を超えて」参加レポート」：
〜・〜
以下、学んだことのメモです。（※下記は私の理解、解釈を表したものなので、各登壇者の本来の趣旨とは異なっている場合があります。）
後藤秀宣氏、「視点」
モデリングにおける「視点」。結局人はモノを自分の立ち位置から相対的に見ている。それが視点。ベクトル構造を持つと言える。渡辺幸三氏の「三面図」も視点の問題を表していると捉えられる。質問が（新たな）視点を作る、というケースもある。
※「渡辺幸三氏の「三面図」」とは、下記記事を参照してください。
ITmediaエンタープライズより、「データ、UI、業務手順の「3要素」をとらえる」：
中西昌武氏、「フォーム検討に対する概念フォーム理論からのアプローチ」
要求分析〜設計において、数理理論による保証が欲しい。理論的裏付けがなければエンジニアリングではない。エンジニアリングにならない限り、勘や経験の世界から脱せられない＝近代化できない＝つらみ、かなしみが続く。
「任意のフォーム（※おおよそ、画面や帳票の入出力項目の定義）」と「任意のリレーショナル・モデルを取るデータ構造」との射影のパターンは有限数であり、形式的に網羅的に列挙できる。射影できないケースは、そうであることを形式的に判定できる。形式化には「隣接行列」を用いている。
※「フォーム」のデータ構造は、「任意のツリー構造型データ」だと（私は）理解しました。つまり、任意のツリー構造のデータとリレーショナル・モデルを取るデータ構造との間の射影のパターンは有限個であり、網羅列挙可能である、という話です。
杉本啓氏、「ドメイン駆動設計 ～ユーザー、モデル、エンジニアの新たな関係～」
Evans氏がDDDにおいて、DDDが古典的OOA/OODと異なると主張したい点とは、、、
(a) 事業課題（問題領域）
(b) 解決領域としてのモデリング
(c) 実装
の三層あるとしたら、開発サイドは(c)だけでなく、(b)のアクティビティをエンジニアリング課題として捉え、ユーザーサイドと共同で進めていこう、という点にあると理解する。その場合は、自ずと(c)のための技術用語ではなく、(b)のための、ユーザー側の問題解決を表現するような“言語”を用いる必要がでてくる。それが「ユビキタス言語」。「ユビキタス」と言うのは、ユーザーサイドと開発サイドでシェアする、というくらいの意味。
久保敦啓氏、「Frameworks We Live By: Design by day-to-day framework development: Multi-paradigm design in practice」
Coplien氏による「Multi-Pradigm Design」の解説。対象の構造に内在する共通性（＝おそらく、目下の要求・要件に依らない対象の本質的な構造）と可変性（＝目下の要求・要件で揺らぎ得る枝葉の仕様）の認識を表す。かつ、「問題の分析」ではなく「課題の解釈」を表す。「解釈」＝「パラダイム」。解釈ゆえに、必ずしも一つの対象に対して唯一に定められるものではない。それが「マルチ・パラダイム」の意味。
日々のソフトウェアデザインで、この共通性・可変性の認識を実装したのがいわゆるフレームワークということ。（※ここに、考え方の枠組みとしてのフレームワークと、ソフトウェア部品化技法としてのフレームワークの一体化を見て取れますね。）また、単一システムの設計時に既にフレームワークを意識することは、そのシステムの“ファミリー”の可能性を拓く。
〜・〜
＜追記＞
以前どこぞやで、『「問題」は認識されるものだが、そのままでは解決できない or 解決が意図されていない。解決するには「問題」を「課題」に転換しなければならない。「課題」とは、解決を意図して「問題」を再構成したもの。』というような趣旨の言説を聞いた／読んだことがありました。杉本氏の講演も、久保氏の講演も、こういった「問題－課題」構造の認識に通じるものがあるように思えました。
◆以上
