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

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

視点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エリック・エヴァンスの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

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

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

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

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

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

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

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

セミナー全体の感想

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

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

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

当日のツイートやその後の関連ツイートがPHPカンファレス2015 PHPメンターズセミナー「モデルを設計せよ！―ドメイン駆動設計を超えて」 - Togetterまとめにまとめられています。こちらも是非ご覧ください。特に最後の杉本さん（@sugimoto_kei）によるドメイン駆動設計の根底にある意図の考察は必見です！

プログラミング道場生 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

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

モデルとは何？

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

• 当システムを誰が使うのか？というのが曖昧だった？
• ドメインエキスパートと、話をしていなかった？
• 船荷証券という管理帳簿で運用されているのなら、逆に船荷証券モデルは最初に思いつくのでは？

こう考えると、DDD本に書かれていた船荷証券の例には、違和感を感じました。（本が伝えたかったと思う事に比べると些細な事ですが・・・）

• Keep：深いモデルに感じていた違和感の意味が、読書会に参加したことで、やっと原因が分かった。
• Problem：読書会感想のまとめを作るのが遅くなってしまった
• Try：参加した三日以内には感想文を出すようにする

前回Try：『発散してきた場合その内容をメモするなどして、ディスカッションはもとに戻して、後日時間を作って改めて発散した内容をディスカッションするようにしてみたい』

• 今回は脱線と言える、話題を超えた発散は無かったと思います。
• もし、発散した話題を改めて後日ディスカッションするとしても、テーマが定まっていないと、コンテキストが定まらず、後日再開というのは、そもそも難しいのではと思い直すようになりました。
• 読書会の目的が、本を読み終えるではなく、知識の探求にあると考えるのならば、話題の発散は、無理の補正する必要はなく、流れに任せておくのが良いように思います。
• このTryは一旦取り下げ、進行役の流れに任せる形で次回は参加しようとおもいます。

前回に「DDDにおけるFATモデルとは？」という話題のなかで

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

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

という課題をあげ、ディスカッション用のサンプルモデルを考えていたのですが、複雑なドメインが何であるかという処で止まっている状況です。

考えていたのは、電車切符販売（他社間の乗継あり）という複雑そうなシステムですが、これがドメイン的に複雑になりえるのかというのが悩んでいるところです。個人的にはコンテキストマップでスコープを限定していけば、ドメイン自体は複雑にならないのではという感想です。（まだ思案中です）

課題がディスカッションをしたいということなので、考えがまとまる前にディスカッション行う事は可能でしょうが、もう少し時間をかけて、議論点を絞り込んだ段階で、再度課題に挙げさせて頂きたいと思います。