-
Notifications
You must be signed in to change notification settings - Fork 5
vol5_20140419
@kuma_nana edited this page May 4, 2014
·
10 revisions
- 日時：2014/4/19
- 場所：コモンルーム中津
- 時間：14:00～17:00
- ハッシュタグ：[#dddosaka]
- 募集ページ：http://dddosaka.doorkeeper.jp/events/10417
- 範囲：第2章 コミュニケーションと言語の使い方 P.30 声に出してモデリングする ～ 第3章 モデルと実装を結び付ける モデル駆動設計 の「モデリングパラダイムとツールによるサポート」 p.49
- 司会： 久保さん( @iteman )
- レポート担当：杉本( @sugimoto_kei )
- やり方：実際に音読した後に、感想を中心に議論する
- モデルの力を借りて開発する。限定された語彙を使うことで、仕様を簡潔に表現することができる。 語彙は限定されているが、その限定された語彙をつかって新しい問題について話し合うことで、語彙の不足が明らかになり、語彙そのものがリッチになっていく（ユビキタス言語をドッグフードとして使いながら、設計～分析～設計～を繰り返していくことで語彙のセットが磨かれていく）。
- 業務用語の体系とユビキタス言語の関係はどうか。
- p.33 末尾には「そうした専門用語（引用者：業務用語）は、言語（引用者：ユビキタス言語）が拡張されたものでしかない」という説明があり、一見、前者が後者を包含する関係のようにも見える。
- 一方、p.31 に出てくる「経路選択サービス」のような用語が、もともと業務用語として存在していたとは考えにくい。こうした語彙はユーザと開発者の話し合いの中で開発されるものであろう。「経路仕様」「輸送日程」といった言葉も、もともと業務用語として存在していたかもしれないが、ユビキタス言語では、より厳密な定義があたえられているに違いない。
- 以上から考えると、ユビキタス言語は、ユーザと開発者の話し合いの中で開発される言語であり、ユーザが理解可能なものではあるが、もともとある業務用語体系のサブセットではないと考えるべきではないか（ユビキタス言語には既存の業務用語に含まれない語彙が含まれるかもしれない）。
- 「1つのチームに1つの言語」が原則だが、コンテキスト(p.342)を切り替えて、複数のユビキタス言語、すなわち、異なるモデルを反映した別の語彙体系を使い分けることは、許容される。― 記録者注：エヴァンス氏が云う「コンテクスト」とは、UMLでいう「パッケージ」のようなモジュール化の仕組みと思う。
- UMLはスケッチ目的では役立つが、緻密に仕様を記述しようとすると問題が起きるという話。
- 全部のクラスを図にするのは大変。
- 振る舞いを十分に記述できない（メモとして記入することは可能だが）
- 書かれた設計ドキュメント ― 設計ドキュメントには、コードの概要ではなく、意図、アーキテクチャなどを記述すべきという話。その点では一般的な認識とそう違わない。
- ユーザとの対話に用いられる「ユビキタス言語」の仕様のドキュメンテーションは、システム内部設計のドキュメンテーションと区別して扱うべきではないか。
- 内部設計文書は、コード自身で語れないことに限定するにしても、ユビキタス言語については、ユーザがコードを読めない以上、ある程度しっかりした説明書が必要では？
- ユビキタス言語とはドメイン層のAPIであるという @Hatajoe さんの卓見に従えば、API仕様書的なものが必要である筈。
- そうした仕様記述も、コードと一体化して管理すべきではないか。JavaDoc 類似の仕組みをベースに、日本語名称等を付加できるような仕組みを用意できるはず。
- 概念間の関係（グラフ構造）を表現する図をコードから自動生成することも可能ではないか（PHPメンターズ後藤さん( @hidenorigoto )の説）。
- 仕様をテストで表現するのではなく、DSLで記述することにすれば？という[後藤さんの提案] (http://phpmentors.jp/post/82335446289/config-dsl) にも関係あるよね。
- この本でのエヴァンス氏はDSLに対してやや懐疑的だが(p.277)、最近はエバンスさんもDSLを全然否定していない。むしろ当たり前のこととして受け入れている様子。
- ここで書かれている「宣言的設計」は、渡辺幸三さんがやっている Xead Driver と同じ路線上にあると思う。
- 宣言的アプローチは、対象領域（ドメイン）を限定しないとうまくいかないのではないか。対象領域を限定することで、手続き的な処理と宣言的ルールを分離し易くなる。例えば、状態遷移図をドメインとする場合、状態の遷移処理自体は（― 記録者注：状態遷移エンジンとして）手続き的に記述する他ないが、状態遷移ルール（状態遷移のトリガとなる条件やの条件下での遷移先状態）は宣言的に記述できる。その点、MDAは対象とする対象領域が広過ぎたのでは？ DSLアプローチは対象領域を限定するので、宣言的な記述が容易になるかも。
- p.40 のクラス図と、p.41 の輸送経路の図は、モデルが違うのか？エヴァンス氏が「ドキュメントと図」で書いていることに従えば、両者は同じモデルの別の図、ということにならないかw
- Viewのみの図とEditしていく図とあって、p.41 図2.5「輸送経路を表す説明のためのモデル」は、モデルというよりはViewとしての図であると解釈した方が良さそう。
- Viewと言っているのは、たとえば、IDEで左側に表示されるパッケージのツリーは、自分で更新するためのものではなく、IDEにより自動的に投影されるView
- Viewのみの図とEditしていく図とあって、p.41 図2.5「輸送経路を表す説明のためのモデル」は、モデルというよりはViewとしての図であると解釈した方が良さそう。
- p.41 の輸送経路の図について興味深いのは、これが、航海一般、経路一般を記述する「タイプレベル」の図ではなく、個々の航海、個々の経路を記述した「インスタンスレベル」の図であるということ(―記録者注：ディスカッションでは「クラスベース／インスタンスベース」という言葉が使われていましたが、正確には「タイプレベル／インスタンスレベル」でした）。
- 説明や理解のための図はインスタンスレベルの方が分かり易い場合が多い。
- 自分で DSL を作る時は、文法（タイプレベル）をいきなり書くのではなく、まず文法に従った記述例（インスタンスレベル）を書いて、その後で文法を書く（久保）
- 渡辺さんの三要素分析法のデータモデル図では、エンティティ型（タイプレベル）とデータ例（インスタンスレベル）を同一モデル図上に記述できる。
- インスタンスレベルの説明の方が、人間にとって理解し易い、という面があるに違いない。
- テストに含まれる assertionと、DSLによる仕様記述は、仕様の宣言的記述である、と言う点では同じだが、前者は具体的な値を指定するのでインスタンスレベルであるのに対して、後者はタイプレベルである。先に出た仕様表現に関する後藤さんの考察には、この点を考慮に入れる必要があるかも。
- p.41 の図はインスタンスレベルだが、これをUMLのオブジェクト図（これもインスタンスレベルの記法）で描くと、かなり分かりにくくなる。その意味で、この図はこのドメインに特化した図であり、一種のDSLになり得るのではないか（このような図をグラフィカルに編集して輸送経路を登録するシステムを考えることもできそう）。―記録者注：この図は、実際、説明のために工夫されたDSLと言って良いかもしれない。
- これを実践している例が、増田享さん（久保さん談）。
- 最低限動くために必要なモノからスタートし、モデルと実装の歩調を合わせて成長させていく。
- ２つの失敗の例のうち最初のケースでは、一応モデルはあった。何が悪かったとエヴァンス氏は考えているのだろう？
- 最初のモデルが大き過ぎ？
- 言語・フレームワークといった実装要素を無視してモデルを作ってしまった？ ― コプリン氏のマルチパラダイムデザインではソリューションドメインの制約を考慮する。
- 分析と設計で担当が分かれるから？
- 分析を先にやってしまってその後設計に移るという手法はダメだということでは？― 現状分析を設計の後に回す渡辺氏のアプローチに通ずる。
- 分析モデルと設計モデルはそもそも別モノと考えていた？ ―例えば、住所録での「任意フィールド」などは業務上は存在しないので、分析モデル上は存在しないが、設計モデル上には存在する？
- ソリューションの構造を分析モデルに戻していくという考えは、マルチパラダイムデザイン、渡辺氏のDOAなどと共通。
- 平鍋さんのアジャイルモデリング
- 実際にモデルと実装の整合をとっていくには、ツールによる支援が重要になるはず。
- ここで言っている（オブジェクト指向などの）「パラダイム」は、ユビキタス言語（≒ドメイン層API）の設計に適用するのか、あるいは、そのAPIを実装するドメイン層の内部設計に適用するのか。
- ユビキタス言語にオブジェクト指向を持ちこむとすれば、例えば、仕入先・部署・従業員は支払先になり得るという点で共通だから「支払先インターフェース」を実装するといった、（ポリフォーフィズムを踏まえた）記述が、ユビキタス言語に含まれる可能性がある。DCIアーキテクチャなどもユビキタス言語の内容に影響を与えるかもしれない。
- 上記のようなことを考えると、ドメイン層の内部設計だけでなく、ユビキタス言語の設計（API設計）が、別の課題として取り扱われる必要があるようにも思われる。エヴァンス氏はこの点についてどう考えているのだろう（―記録者注：今後のお楽しみ）。