PHP Mentors

プログラミング道場生 kawakawaです。
ドメイン駆動設計読書会の第6回に参加してまいりましたので、感想を報告させていただきます。

読書会の内容は、レポート担当者さんにより、wikiにまとめて頂いております。
第6回「ドメイン駆動設計読書会@大阪」公式レポートWiki


今回でDDD本の第１部の範囲が終読致しました。
そこで、第１部全体での振り返りを行いたいと思います。

(2014/06/10 追記）
本から抜粋と記しているところを、抜粋元が不明瞭とのご指摘を頂きましたので、引用元箇所を明記しました。

ドメイン、モデル、ユビキタス言語の関係性

DDD本（第１部範囲）から記載されていた言葉を抜粋すると、

ドメイン

「第１部 ドメインモデルを機能させる」（中国世界地図の後）
すべてのソフトウェアプログラムは、それを使用するユーザの何らかの活動や関心と関係がある。ユーザがプログラムを適用するこの対象領域が、ソフトウェアのドメインである。ドメインの中には、物理的な世界をふくんでいるものもある。

モデル

「第１部 ドメインモデルを機能させる」（中国世界地図の話）
モデルとは簡素化である。つまり、当面の問題を解決する上で関連する側面を抽象化し、それ以外の詳細を無視することによって行われた、現実に対する１つの解釈なのだ。

「第2章 コミュニケーションと言語の使い方」（章の冒頭）
モデルとは、プロジェクトに携わる人々の頭の中で構築された概念の集まりであり、ドメインについての洞察を反映した、用語と概念間の関係性からきている。

ユビキタス言語

日本語推薦文：榊原 彰氏
書籍の冒頭からドメイン知識を得ることの有用性と、抽象的な議論に陥らずにドメインエキスパートとIT 技術者が有益な協力を行うことの重要性に言及している。
この書籍の中で新しく提唱された言葉である「ユビキタス言語」という考え方はまさにそうした根本概念を端的に表すものだと言ってもいいだろう。

日本語推薦文：平鍋健児氏
私自身がDDDの中で特に気に入っているのは「ユビキタス言語」。
ケント・ベックがエクストリームプログラミングにおいて「メタファ」（Metaphor）というプラクティスで表現しようとしたのは、顧客から開発者までが会話できる共通ボキャブラリの提供です。
これこそが、DDDにおいてユビキタス言語と呼ばれているプラクティスであり、ソフトウェアデザイン活動のコアであろう、と私は考えています。

（※2014/05/25 追記）
kumamidoriさんから、DDD本巻末に記載されている用語解説から、説明文を引用されてはと、ご提案頂きました。
確かに、その方が適切かと思いますので、下記に用語解説から、それぞれの解説文を記載致します。
（上記の単語解説文は、DDD本第1部範囲から、私が抜粋したものとなります）

DDD本用語解説

• ドメイン・・・知識、影響、または活動の領域。
• モデル・・・ドメインにおける選択された側面を記述し、そのドメインに関連した問題を解決するのに使用できる抽象の体系。
• ユビキタス言語・・・ドメインモデルを取り巻いて構築され、チームのあらゆる活動をソフトウェアと結びつけるために、チームメンバ全員によって使用される言語。

DDD本の第１部から、私が感じ取ったイメージを図にすると下記のようになりました。

図１：ドメイン_モデル_ユビキタス言語の関係図

ドメインは、見方や観測者によって姿・形が変わる雲のようであり、そこから、抽象化（≒誰が見ても同じ形に見えるように）取り出したのがモデルで、モデルはユビキタス言語にて構成されているイメージです。

モデルは、モデルA・B・Cのように、抽象化した内容が異なれば、その分ドメイン内に複数存在することになります。
抽象化によっては、ユビキタス言語（語彙２）を通じて、モデルAとBが重複しているように、モデル同士の領域が重なる事もあります。

ユビキタス言語は、ドメインに対してユニークであり、ユビキタス言語（語彙１～５）は、それぞれ個別の語彙である事を示しています。

（※2014/05/22 追記）
久保さんから、「モデルの名前も、ドメイン内でユニークであるのなら、ユビキタス言語の語彙といえると思います」とのご指摘を頂きました。
なるほど、確かにモデル名もユビキタス言語と言えると思います。ご指摘有難うございました。

DDDにおける「モデル」とは？

DDD本では、モデルは関係者間のコミュニケーションツールであると、書かれていますが、 別の見方をすると、モデルこそが、開発者とドメインエキスパートが、ドメインを認識しあえる 唯一のツールでは無いかと思っています。

モデルという語彙が示すものという話になりますと、言葉の綾的な処がございますので、 実際にモデルはどのようなものなのかを考えてみたいと思います。

まず、思い浮かぶのが図・UMLや、業務分析シートや要求仕様書などのドキュメント関係を思い浮かべますが、DDD本に記載されていたモデルとは、

「第2 章コミュニケーションと言語の使い方」「ドキュメントと図」（中盤）
言語に対するこうした変更は、ドメインモデルに対する変更として認識され、用語の意味が変わった場合には、チームがクラス図を更新して、コード中のクラスやメソッドの名前を変えたり、ふるまいを変更したりすることにまでつながる。

「第2 章コミュニケーションと言語の使い方」「ドキュメントはコードや会話での表現を補わなければならない」（最初）
動作しているコードが嘘をつくことはないが、他のドキュメントだとその可能性がある。
動作しているコードのふるまいには、あいまいなところがないのだ。

「第2 章コミュニケーションと言語の使い方」「ドキュメントと図」（後半）
常に覚えておいて欲しいのは、モデルは図ではないということである。
図の目的は、モデルについてコミュニケーションし、説明するのを助けることにある。

「第3 章モデルと実装を結びつける」「モデル駆動設計」（後半）設計で使用する用語法と責務の基礎的な割り当てをモデルから引き出すこと。コードはモデルの表現となるから、コードに対する変更はモデルに対する変更になるかもしれない。
その影響は、プロジェクトの他の活動全体へと適宜伝わっていかなければならない。

「第3 章モデルと実装を結びつける」「骨格を見せる：なぜモデルがユーザにとって重要なのか？」（終盤）

モデルが明らかになれば、ユーザはソフトウェアの潜在能力にもっと触れられるようになり、ふるまいは一貫した予測可能なものになる。

と記載されています。 

一般的にイメージしがちな、図・UMLなどドキュメントを、モデルと見なすことに、警告を示されています。

確かに、図・UMLだけでは、簡易表記により、誤解を招いたり、逆に詳細に記述し過ぎて、視認性を悪くしたりして、モデルの意図・目的が上手く伝わらない危険性があるかとは思います。

しかし、コミュニケーションツールとしてのモデルを考えた場合、プログラムコードだけでは、ドメインエキスパートとコミュニケーションとるのは難しそうです。 

やはり図やUMLなどドキュメント類が欲しい処です。

DDD本で紹介されていた手法としては、先にプログラムコードを書き、その補足として、図・UMLを書きなさいと記載されておりました。 

従来の図・UMLからプログラムコードへの手法と逆になりますが、先にプログラムを書くことで、図・UMLで設計する必要がなくなり、図・UMLが無駄のない、目的を明確化したドキュメントになるという事で、成程と思いました。

ウォーターフォールでDDDはできるのか？

ウォーターフォールの開発環境でも、DDDはできるのでしょうか。
DDD本で、ウォーターフォールに関して記載された箇所を抜粋すると、

「第1 章知識をかみ砕く」「知識のかみ砕き」（中盤）
旧来のウォーターフォール手法では、ビジネスエキスパートがアナリストに話をして、アナリストがかみ砕き、抽象化して、その結果をソフトウェア作成者であるプログラマに伝える。
このアプローチがうまくいかないのは、フィードバックが完全に欠けているからだ。
アナリストはモデルを作成する全責任を負っているが、基になるのはビジネスエキスパートから得た情報だけだ。
プログラマから学んだり、ソフトウェアの初期バージョンを体験したりする機会は全くない。
知識は一方向に少しずつ流れるだけで、蓄積されないのである。

「第1 章知識をかみ砕く」「知識のかみ砕き」（後半）
チームメンバ間のやりとりは、メンバ全員がモデルを一緒にかみ砕くことで変化する。
ドメインモデルを絶えず改良すると、開発者は、自分が力を貸しているビジネスにおける重要な原理を習得するように強いられ、機械的に機能を作り出すことがなくなる。
一方、ドメインエキスパートは、自分の知っていることを蒸留して本質を抽出するように強いられることによって、しばしば自分の理解を精緻にし、ソフトウェアプロジェクトが必要とする概念の正確さを理解するようになる。

「第1 章知識をかみ砕く」「知識のかみ砕き」（後半）
改善されるにつれて、モデルは、プロジェクトの中を流れ続ける情報を体系化するためのツールとなっていく。
モデルは、要件を分析することに焦点を合わせているが、プログラミングや設計とも深く相互作用する。好循環が起きれば、こうしたモデルの性質によってチームメンバのドメインに対する洞察が深まり、状況がより明確に理解できるようになって、モデルがさらに精緻化される。
このようなモデルは、決して完成することがない。
代わりに、進化していくのだ。

「第1 章知識をかみ砕く」「継続的学習」（後半）
アプリケーションのコアは別にあることがわかったので、その側面を舞台の中央へ持ってくるようにモデルが変更されたのである。
ドメインエキスパートがより多くを学んだことで、アプリケーションの目標が明確になったのだ。

ウォーターフォールでDDDが、出来る/出来ないとは書いていませんが、アジャイル開発と比べて次の点でDDD実践は難しそうです。

• モデルを修正・補正する機会が無い 
• ドメインエキスパートが情報蓄積・学ぶ機会が無い 

フィードバッグループが大きくなってしまうという、ウォーターフォールのデメリットがネックになりそうです。

余談ですが、読書会で出た話として、

• アメリカは内製開発が多く、日本は外部開発が多い 
• 日本の場合、SIerのほうが、顧客よりもドメインエキスパートになっているときがある 

という話題がありました。

これらから推測すると、

• 日本はSIerなど外部がウォーターフォールで開発を行う。 
• 開発で得られた知識は、顧客ではなく、SIerに蓄積されていく。 

このような流れになっていると思われます。

ウォーターフォール開発については、開発側視点で納期や予算などで問題が多いという議論は多いですが、発注側の「知の蓄積欠如」・「学びの機会損失」という視点は想定していなかったので、面白い発見ができたかなと思います。

第１部のまとめ

ソフトウェア開発を「設計」と「実装」にわけると、それは「戦略」と「戦術」のような関係だと捉えています。
今まで、「戦術」部分を磨くべく、学んできましたが、「戦術」だけでは太刀打ちできない、「戦略」の壁を感じる事が多くなってきたので、「戦略」を学ぼうと思ったのが、DDD本を読み始めたキッカケでした。

DDD本第１部を読み終えて思うことは、この本は「戦略」方法が直接書いているわけではなく、「戦略」のための「戦略」が書いているのだと。
その為、多少判りにくい処のはありますが、まずは最後まで読み終えてみたいと思います。

また、第１部で生じた疑問点は、第２部以降、続きを読み続けていく中で、解消していきたいと思います。

• 疑問１ ：深いモデルを作りだすコツはあるのか？ 
• 疑問２ ：DDDの実践方法（プラクティスやツールなど）。どうやって現場に広げるのか。 
• 疑問３ ：複雑なドメインとはどのような事を示すのか？ 

振り返り

Keep

• 第１部まで読み終える事ができた

Problem

• 第１部内でも理解が足りない処がある（特に第3章）
• 感想文の提出が1週間超えてしまった。

Try

• 第１部読み直し。
• 感想文提出１週間を目指す。

プログラミング道場生 kumamidoriです。
5月6日に、「ドメイン駆動設計」読書会の第6回を行いました。今回で、第1部「ドメインモデルを機能させる」を読了できました。DDD本の基礎編を終了した形となります。公式レポートはこちらにあります。
今回は、スペシャルなゲストとして、IT勉強宴会の主催をされていらっしゃる、佐野さんにお越し頂くことができました。大変有意義なディスカッションとなりました。惜しみないシェアに感謝いたします。

この記事では、基礎編終了という１つの節目にあたり、個人的なまとめとして、下記の2テーマについて書きたいと思います。

1. 「ドメイン駆動設計とは何か」を簡単に言うとしたら、どんなふうに説明できるか？
2. CodeIQに出題されていた、増田亨さんからのオブジェクト指向設計の問題（これまでの知識を使って自分なりに考えてみた）

「ドメイン駆動設計とは何か」を簡単に言うとしたら、どんなふうに説明できるか？

以前、飲み会で、デザイナさんに何気なく読書会の話をした時に、「ドメイン駆動設計？何ですか、それ？」と自然に聞き返されて、答えられなかったことがあります。（隣に座っていたエンジニアさんが、「それは、お名前ドットコムで、ドメイン取ってから開発することです」と真顔でジョークを言っておりました）。
自分なりの説明を書いてみたいと思います。

・・・・・・・・・・・・・・・・・・・・
ドメイン、という英語は、直訳すると、支配領域、という意味です。
システム化したい対象領域、というイメージが近いです。
たとえば、私が家計簿アプリをこれから作るとしたら、「預金」にはどういう種類があるものか？とか、残高とはどうやって計算するのか？とか、家計簿に関する知識をある程度持っていないと、作り始めることが難しいです。ソフトウェア開発の難しさは、プログラミング言語の習得とか、フレームワークの使い方とか、そういった解決方法ももちろん難しいわけだけれど、それ以上に、実は、そもそも作ろうとしている仕様そのもの、問題そのものが複雑で難しい。ごちゃごちゃとした仕様、対象を、分かりやすく表すために、まずは言葉を使って、問題の概念をきちんと整理すること、モデルを考えること、こういった設計情報を、そのまま実装コードにもシームレスに反映させましょう、という、考え方のことです。分かりやすく設計することで、スピーディに機能拡張ができると同時に、保守もやりやすくなります。
・・・・・・・・・・・・・・・・・・・・

CodeIQに出題されていた、増田亨さんからのオブジェクト指向設計の問題

CodeIQの増田亨さんの問題、”「顧客区分」を列挙型で宣言し、「顧客区分」ごとに異なる振る舞いを持たせてみましょう。” を読んで、考えてみました。問題文の詳細は、設問1チラ見! というボタンから見ることができますので、そちらをご覧下さい。増田さんの出題内容とは、ずれている回答になってしまうのですけれども、これまで読書会を通して学んできた知識のまとめのつもりで、サンプルコードを作りました。

このサンプルコードで、元々の問題から大きく変えてしまっている箇所

• 本来は列挙型で書く問題なのだけれど、そうではなく、DB設計のデータ仕様として考えました。
• 回答言語：問題はJavaなのだけれど、PHPで書きました。

想定した仕様

設問からはユースケースが見えづらいので、まず、システムの目的を想像して、言葉にしてみました。このシステムでは、`顧客`とその属性（料金等）が主な関心事と思いました。

業務

• 営業は、自分の顧客リストを持っている。
• 営業は、顧客から料金を受領する仕事をするものとする。
• このアプリケーションは、営業が顧客を管理することを目的とする

機能

• 顧客 には、３つの 顧客区分 がある。
• 受領する 料金 は、顧客区分に応じて決まる。

詳細仕様

• 顧客区分が、将来減った場合 （例：こどもが廃止された）
  • 旧料金設定しか持たない顧客については、今回のアプリケーション外とする（運用で別途対処するイメージ）
• 顧客区分が増えた場合 （例：乳幼児が増えた）
  • 新料金を顧客に設定する
• 料金が変わった場合 （例：100円が200円に値上がりした）
  • 料金を更新
• 「料金の受領」以外にも仕事が増えた場合 （例：顧客区分に応じて、異なる文面で通知メールを送信する）
  • 「顧客区分毎の文面」を管理対象に加える

モデリング

上記から、問題とは離れてしまいますけれども、顧客区分をデータ仕様によって表すことが、もっとも柔軟に拡張性を持たせられるように思ったので、それで考え進めてみることにしました。

データ仕様

データ仕様（渡辺幸三さんの記法（文末参考リンク[※1]）を参考にした書き方です）

UML

• アプリケーションレイヤーとドメインレイヤーの分離を考えました。
• 料金 は、誰に聞くか？で悩んだ結果、顧客 に聞くことにしました。
• 区分による振る舞いの制御は、継承で表現しました。

実装環境

Symfony2.4.4 ベースで作成したミニマムなコンソールアプリケーションを書きました。Githubのリポジトリはこちらです。

サンプルを書いた感想

没にした、一番最初のモデリングでは、「ものすごく変」なUMLを書いてしまい、一度捨てて、やり直したのが上記です。変になってしまった敗因としては、「設定情報は、普通、ブート時に最初からロードするよね・・・」といった、手続き的なところからスタートしてしまったからだと思います（汗　 データ仕様の方はまともに書けていたので、それを足がかりにして、「料金を、誰に聞くか？」を入り口としてやり直したことにより、ましになったような気がします・・・。

参考

• [※1] データモデリングのガイド
• オブジェクトモデリングとデータモデリング
• ドメインとアプリの区別を意識したコーディングを学ぶ

モデルとは何？

• 図は詳細に記すると全体がぼやけてしまい、逆に省きすぎると詳細が分からなくなる。
• 図だけでは概念の意図が伝わらない。別の説明が必要となる。
• 図はメンテナンスコストがかかり、モデルの変化に追随できない可能性がある。

最近入門致しましたプログラミング道場生 kawakawaです。

宜しくお願い致します。

ドメイン駆動設計読書会の第3回目に参加してまいりました。

今回も前回同様2グループに分かれ、それぞれディスカッションを行い、最後にその内容の共有を行いました。

レポート担当者さんによるまとめはwikiにまとめられています。

第3回「ドメイン駆動設計読書会@大阪」公式レポートWiki

個人的勉強になった点

■１章の役割とは？

今回は第1章メインに議論したのですが、チーム１での発表にあった、

「この章の存在意義は、DDDの形や理想を示していて、目標にせよという意図を感じた」

という言葉に尽きると思いました。

最初、１章を読んだ時は、DDDを簡易に説明しているだけで、触りしか書いていないと思っていたのですが、上記のようにDDDの目標を提示しているという見方で意識してみると、確かに今後の章でキーとなる単語が多くちりばめられており、この章がDDDを濃縮した章という事を感じる事ができました。

（キーとなる単語：『ドメインエキスパート』、『共有された言語』、『フィードバックループ』、『モデルの蒸留』など）

特に気になった単語は『フィードバックループ』、『モデルの蒸留』です。

DDD本を読み始めたきっかけでもある、開発を進めながらモデルを変更するなんて可能なのか？果たして実現可能なのか？という疑問に応えてくれそうだからです。

この先読み進めるにあたって、この点を重点的にチェックしていきたいと思います。

■ドメインモデルに込める意思

前回の第2回読書会では、モデルとは抽象化であるという話がありました。

そして今回は、”ドメインモデル”とは何だろうかという質問が挙がりました。

色々意見が出たのですが、私はその中の１つであった、

ドメインモデルとは、『目的をもった抽象化』ではないだろうか

という話に興味を持ちました。

ドメインモデルには、何であれ何かしらの問題を解決しようとする意志が込められているというのがその議論です。

その観点から考えると、モデルのリファクタリンクとは、提示されたストーリ（シナリオ）を解決できるのか、モデルが問題の核心を突いているのか検証する行為と見る事ができます。

モデルのリファクタリングと言われると何やら難しい事を行っているかのように思っていましたが、このような視点で見てみると、意外と難しい事では無いかもしれません。

■顧客にドメインモデルの有効性を伝えるには？

疑問に思うことの１つに、ドメインモデルを構築することが、ソフトウェア開発において重要な手助けになるという事を、ドメインエキスパートでもある顧客にどのように伝えれば理解頂けるのだろうかという疑問がありました。

挙がった意見の中で一番納得したのは、

アジャイル的な運用をすることで、プロジェクトを小さく回せは、小さいながらも成功体験を顧客にも体験してもらう事ができる。そうすれば、いつかはドメインモデルの有効性について、理解していただけるのではないだろうか。

というものでした。

言葉で説明し辛い事は、実際に体験して頂くのが一番ですからね。

アジャイル開発の新しい見方を教えて頂いたようで、大変納得いきました。

■DDDにおけるFATモデルとは？

ディスカッションで、なんでもかんでもドメインに詰め込む、FATモデルについて話題に挙がりました。

（書くまでもありませんが、MVCパターンにおけるFATモデル、痩せたモデルとは意味が異なります。私は昔といっても最近まで混同してました…汗）

その場では納得していたのですが、後になって考えてみるとDDDにおけるFATモデルとはどのようなものなのでしょうか？

単純に考えると、オブジェクトを多数持つモデルで、蒸留することで、コアドメインへダイエット出来るものというイメージがあります。

それに加えてFATモデルには、元々ドメインが複雑なため、詰め込まなくてはならなかったカオスモデルと呼ぶべきようなものも含まれているような気がしてまいりました。

DDD本の序章には『複雑なドメインの設計は、モデルに基づかなければならない』と記されていますが、具体的にはどのようにすれば良いのか、私はまだ判っておりません。

今後は、DDDにおけるFATモデル（≒カオスモデル？）についてもディスカッションしていければと思います。

関連リンク

参加された方のブログです。

• 読書会「第２回ドメイン駆動設計読書会@大阪」に参加した（@84zume）

当日のツイッターまとめはこちらです。

• 第3回「ドメイン駆動設計読書会@大阪」togetterまとめ

振り返り

• Keep：積極的に発言することで、ディスカッションに参加する事が出来、大変勉強になった。
• Problem：ディスカッション内容が脱線した際、戻すべきか発散させるべきか悩む時がある。
• Try：発散してきた場合その内容をメモするなどして、ディスカッションはもとに戻して、後日時間を作って改めて発散した内容をディスカッションするようにしてみたい

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さんインタビュー( 前編 )

プログラミング道場生 kumamidori です。

IT勉強宴会の「ドメイン駆動設計を知ろう」セッションに参加したことがきっかけで、「エリック・エヴァンスのドメイン駆動設計」について、理解を深めるための読書会を企画しました。

20名程度の方から参加登録がありました。イベント詳細はこちらです。

2014年2月22日、大阪DDD読書会の第１回を行いました。隔週で6回か、もうあと数回行う予定です。

節やページ単位を交代で読み上げ、交代のタイミングと最後にディスカッションを行います。それぞれの回でレポート担当者を決め、担当者はWiki ページにレポートを記述します。

今回のレポートWikiは @kawakawa さんが丁寧にまとめて下さいました。こちらです。

参加者の皆様、ありがとうございました。

振り返りを書きます。
- K

• 隔週ペースは、少しずつ記憶があるうちに進められて良さそう。
• 録音しておいて良かった（後から分からなかったところを追えた）。
• Wikiでレポートを残す習慣も、次回やるときの復習になって良い。

• 久保さんへ分からない点を質問する形が多く、意見や解釈の表明、過去の経験との関連付けで考えを述べる形が少なかった
• 個人的な反省：予習でメモを残してくる。

• 次回は人数も多いので、「１人１個は必ず何か言いましょう（印象に残った箇所、解釈、意見の表明、良い質問等）」というルールでお願いしようと思います

PHPメンターズ道場生 kumamidori です。
12月13日（金）にインターネットイニシアティブジャパン関西支社で開催された、「第28回関西IT勉強宴会 “ドメイン駆動設計を知ろう”」に参加しました。

• 第28回関西IT勉強宴会 “ドメイン駆動設計を知ろう”
• 関西ＩＴ勉強宴会のページ

講師は、PHPメンターズの後藤さんと久保さんです。

実は、DDD（ドメイン駆動設計）については予備知識の無い状態でした。この機に勉強してみようと思って申し込みました。 師走の、しかもいかにも忘年会とかぶりそうな日程だったのに、参加者は39名にのぼり、開始時間にはほとんどの方が着席されていました。 注目度の高さがうかがえます。 業務システムの設計者だけではなく、PHP系Webエンジニアの方にも数名お会いできました。 セッションは、前半の基礎編と、後半の発展編に分かれていて、最後に質疑応答が1時間（！）ありました。

[前半]基礎編（講師：後藤さん）

冒頭で、参加者に対して、DDD本（「エリック・エヴァンスのドメイン駆動設計」）を持っている人のアンケートを取っていました。半数近い方の手が挙がりました。

• kindle版はこちら

ところが、「実践している人は？」となるとほとんどおらず、「全部読んだ人は？」という質問になると、該当者が講師陣のみに。興味はあるのだけれど・・・という感じですね。 以下、参加メモです。

ドメインレイヤー

• ドメインとは、知識、影響、または活動の領域。（システム化する対象領域、というイメージが近いと思います）。
• システムは、プレゼンテーションレイヤー、アプリケーションレイヤー、ドメインレイヤー、インフラレイヤーに分けられる。ソフトウェアの本質はドメインレイヤーにある。

ドメイン駆動設計とは

• フレームワーク、語彙である。特定のパラダイムには依存しない。
• 「DDD本」の見開きにある図のとおり、「ユビキタス言語」と「モデル駆動設計」が根幹となる。※「ユビキタス」は、どこにでもある、の意。
• ドメイン知識とモデル駆動設計で、共通の語彙として、「ユビキタス言語」を用いる。（チームメンバー全員に使用される言語）。
• DDDでは、分析→設計→実装のサイクル、すべてにおいて、モデルが基礎となる。

ドメインモデルとは

• たとえば、ドメイン定義、ドメイン辞書、概念モデル、ユースケースモデル、フィーチャーモデル

フレームワーク

構成要素（ビルディングブロック）

• モデルを表現する
• データ：エンティティ、値オブジェクト、集約・・・
• 機能：サービス、ファクトリ、リポジトリ・・・

[後半]発展編（講師：久保さん）

問題ドメイン・解決ドメインとモデリング・設計・実装

ドメイン工学に基づくソフトウェア開発

質疑応答

モデルとは何か、を中心にディスカッションが行われました。参加者の方からレポートが公開されているので、 文末の[関連リンク]を参照頂ければと思います。

感想

「深いモデル」について

スライドには出ていなかったのですけれど、後藤さんのお話の中で、「深いモデル」という言葉が出てきて印象に残りました。DDD本から引用します。

深いモデル（DDD本の20ページより）

役立つモデルがすぐに見つかる表層にあることはめったにない。
ドメインとアプリケーションがやるべきことを我々が理解するようになるにつれて、たいていの場合、表層にあり
最初は重要と思われたモデル要素を廃棄するか、それらのモデル要素を違った視点で見ることになる。
すると、最初は考えつかなかった、それでいて問題の核心を突くような、うまい抽象が現れてくるのだ。
（中略）
知識のかみ砕きは探求だから、最終的にどこへ行き着くかはわからないのだ。

Web開発とDDD

Webサービスをメンテナンスする上で私が日々やっていること、

• 仕様を調査して簡単な文書や図を書く
• 開発チームメンバーと仕様を共有し、議論する
• 「作りながら考える」

といった活動の中に、DDD的な考え方はすでに含まれていると感じました。 DDDという言葉の響きが難しそうに聞こえてしまうけれど、身近であり、特別な難しい技法ではない、明日の仕事の役に立つようなものでした。
ちょうど最近、下記のような実践談がシェアされていました。

• SNSチームでのドメイン駆動設計の実践
• Railsでサービスとフォームを導入してみる話 - 「ドメイン駆動設計（DDD）という考え方」

私にはまだ、実践のイメージがつかめていないので、本を読みつつ、小さなサンプルで実際にやってみるところから始めていきたいと思います。

リファクタリング？

セッション終了後の雑談の中で、テストやリファクタリングが今の自分のテーマで、といったことをお話したところ、「モデルなきリファクタリングには意味が無い」とのご指摘を頂きました。

DDD情報源リンク

• 無料のDDD本ダイジェスト
  • 「Domain Driven Design（ドメイン駆動設計） Quickly 日本語版」

コンパクトに要約されている良い情報源です。まずこちらを読んで概要をつかむのが良さそうです。

関連リンク

• 関西ＩＴ勉強宴会のブログです -2013-12-13（金）第28回関西IT勉強宴会　ドメイン駆動設計を知ろう
• ドメイン駆動設計に出てくる「モデル」とは何ですか？～第28回関西IT勉強宴会の感想
• ドメイン駆動設計と業務分析の違い - 第28回 関西IT勉強宴会 -

余談ですが、続けて行われた忘年会にも行ってきました。皆さん頼もしく親切な方ばかりでした!

主催の佐野さん、皆様、ありがとうございました。

2015年4月25日に大阪で開催された関西IT勉強宴会で、DDDのモデリングについて発表しました。

• 第40回IT勉強宴会【DDD,UML,DOA競演モデリング発表会２】
• DDD,UML,DOA競演モデリング発表会２＜第40回IT勉強宴会in大阪＞ - ＩＴ勉強宴会blog
• 発表の録画（YouTube）
• モデリングの標準問題から学べること: 設計者の発言

発表で利用したスライドと、実装したコードのリポジトリリンクは以下です。

• phpmentors-jp/flower-shop

当日の内容については、togetterのまとめをご参照ください。

今回この勉強会で私の現時点のDDDについて発表する機会ができたのは、とてもよかったです。モデリングという視点と経験の豊富な方々のあつまる勉強会で、いろいろなフィードバックも頂けてとても貴重でした。

また、昨日は私を含めて3つの発表があったわけですが、井田さんの問題設定とアプローチや話の組み立て方などものすごく勉強になりますし、TH法の堀越さん、石井さんの話でも使い込んできたパターンの形などとても納得感がありました。井田さん、堀越さん、石井さん、ありがとうございました。

そして毎度このような勉強会の開催にご尽力されている佐野さん、本当にありがとうございました。

2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。

セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。

今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。

レポートは @smori1983 が担当させていただきます。

当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントにて公開されています。Coplien さんのおもしろTシャツにも注目しながら、ぜひご覧ください。

• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 1 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 2 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 3 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 4 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (extra)

全体の流れ

全体の流れとしては、1980年代以降のソフトウェア開発の歴史を、主にオブジェクト指向に対する考え方の変遷を通して振り返りつつ、MPD と DCI の関係性に迫るものとなりました。

オブジェクト指向（1988）

当時は C++ の他に、テレコム業界向け言語である CHILL や、軍需産業向け言語である Ada などの言語があり、それらの言語がオブジェクト指向なのかという議論がされていました。

最終的に C++ が残ることになりますが、C++ の作者である Stroustrup 氏は、そもそも C++ をオブジェクト指向言語ではなく、マルチパラダイム言語と定義していたことに注意する必要があります。

当時考えられていたオブジェクト指向の構成要素は次の3項目でした。

1. inheritance / 継承
2. polymorphism / ポリモーフィズム
3. instantiation / インスタンス化

1994年に Coplien さんは David Weiss 氏と Robert Chi Tao Lai 氏とともに仕事をしますが、その時、共通性／可変性分析を通じて、ソフトウェアファミリの振る舞いなどを特徴づけ、当時取り組んでいたソフトウェアのための DSL(Domain Specific Language) を開発しました。開発言語は C でした。

この、共通性に注目してグルーピングしたものをファミリと定義する方法は、Weiss 氏らが考案したFAST(Family Abstraction Specification Technique) という手法に基づいています。

DSL は小さなドメインを対象にしていて、ドメインが変化しない限りはうまくいったそうですが、ドメインは変化していくものです。DSL は、デバッガなど周辺技術との密な関係性の中で成立するため、その変化に対しては脆いという問題がありました。

ただし、共通性／可変性分析自体は非常に有用で、ドメイン分析に対しては非常に多くの収穫があったそうです。

分析の結果得られる共通性／可変性テーブルの内容の埋め込み（注: 解決ドメインの抽象による実装）に関して、

• DSL で埋め込むと、固くなりすぎ、脆くなる。
• C で埋め込むと、言語特有の制約が多く、開発者の intentionality（意図）がわからなくなる。

という課題がありましたが、C++ を用いることで、よりうまくいくようになりました。

オブジェクト指向（1995）

Coplien さんは、C++ を

共通性／可変性分析のための、汎用言語キットである

と捉えます。

その視点で見たオブジェクト指向は、次の4項目の構成要素で理解されるようになりました。

1. Common Signature
2. Common Data
3. Variation in Data
4. Variation in Algorithm

また、polymorphism / instantiation は、共通性／可変性のバインディングタイム（注: 共通性／可変性が変数に束縛されるタイミング）の選択の問題として捉え直されることになりました。

オブジェクト指向（DCI 時代）

Coplien さんによれば、更にこの後、3段階の気付きを経て、現在のオブジェクト指向理解へとつながっているそうです。

1段階目: There  is no OO in C++

• 2010年くらいまでは、オブジェクト指向という言葉を、抽象データ型（ Abstract Data Type: ADT ）という意味で使っていた。
• C++ は実際には抽象データ型ではなく、具象データ型（ Concrete Data Type: CDT ）であるということ。

2段階目: There are no objects in source code

• C++ プログラムはソースコードである。
• そこにはオブジェクトは存在しない。ソースコードに記述しているのはクラスである。
• 多くの人々が Java などの言語でやっているのはクラス指向プログラミングである。

3段階目: OO is mental model

• Trygve Reenskaug 氏とオブジェクトとは何か、オブジェクトパラダイムとは何かについて話し合い、DCI が生まれた。
• DCI は、抽象データ型の実装を意味したこれまでのオブジェクト指向とは別の視点を与える。
• 実行時におけるオブジェクトのネットワークがどのように問題を解決するかに注目する（ Alan Kay の定義）。
• 我々はクラスとロールをごちゃまぜにして考えていた。
  • 抽象データ型について考えるのがクラス指向。
  • ロールについて考えるのがオブジェクト指向。
  • 抽象データ型＋インスタンス化がロールを実行（play）。

MPD と DCI

MPD は、クラス指向のレイヤーにおいてドメイン分析を行う時、ソフトウェアファミリの共通性／可変性分析を通じてドメインモデルを構築する手法を提供します。

DCI は、我々のメンタルモデルに基づいて、オブジェクトどうしの相互作用を定義します。そこでは、抽象データ型としてのクラスに具体的なロールを注入されたオブジェクトが、特定のコンテキストのもとに配置され、相互作用するという、動的な側面を捉える方法を提供します。

以上を簡単にまとめると、次の表のようになるかと思います。

歴史的には MPD が先行しました。それは後に、モデルの静的な構造の分析を行うための領域を担う設計方法論という捉え直しがされました。そして、オブジェクト指向に対する新しい視点を提供する DCI が、クラス指向では扱うことが難しかった、モデルの動的な関係性を捉えるための方法論として提起されています。

Time and Space と DCI における共通性／可変性

DCI は、オブジェクトどうしの相互作用に注目します。つまり基本的には時間の経過（シーケンス）が意識されます。しかし、あるロールを付与された複数のオブジェクトが配置されてこそ、相互作用が成立するものです。

コンテキストとは、このように、ある状況に参加する主体の空間的配置と時間的な相互作用の総体として捉えられるものと言えます。

ここで、日本人にとってはありふれた「間」という概念が取り上げられました。具体例としては次のようなものが話題にあがりました。

• 歌舞伎（ Coplien さん）
• 龍安寺の石庭（ @koriym さん）

また、アレグザンダーの考案したパターンランゲージに話が及びました。パターンランゲージは、建築の構造（空間的なパターン）だけではなく、その構造が生み出す人々の相互作用（時間的なパターン）も内包したものとして理解されるべきです。

pattern of behavior = pattern in space + pattern in time

セッションの終盤では、このように、DCI が担う領域における共通性／可変性概念の適用可能性が示唆されました。

さいごに

会場を提供していただきましたヴァル研究所様、DCI Tokyo スタッフの皆様、今回もすばらしいイベントとなりました。ありがとうございました。

次回は、ワークショップ形式での開催も視野に入れながら、DCI Tokyo 3 が開催されることと思います。MPD / DCI / Lean Architecture に興味のある方は、ぜひご参加ください。