大阪DDD読書会vol.5、「モデル駆動設計」前半、復習メモ

2014-04-27

4/19に大阪DDD読書会vol.5で、第2章「コミュニケーションと言語の使い方」後半から第3章「モデルと実装を結びつける」の前半まで読みました。 (公式レポートWikiはこちら)。

感想や復習メモをつらつらと書いていきます。

モデル駆動設計について

「モデルを使っていく」とはどういうことか?

本の中で

荷受け地や荷出し地などがあって、これらを全部[経路選択サービス]に与えると、 必要なものがすべて揃った[輸送日程]が戻ってくる。

という説明と

[経路選択サービス]は、[経路仕様]を満たしている[輸送日程]を見つける。

という表現を比べて、後者が簡潔だ、という話が出てきます。

モデリング作業として、実際にテストコードを書いて実行してみるまでもなく、ただ言葉にしてみるだけで、ある程度試していくことができるわけです。「モデル駆動設計」という言葉の響きは難しく聞こえるけれど、想像していたよりもずっと簡単なことを言っている?

ユビキタス言語、ドメインモデル、コードを結びつけるアプローチとして、既存で近いことができるツールには何があるか?

「手で用語集やモデル図を直すなんて、やってられない。ツールを使うことになるのでは」という話です。

コードからのドキュメント生成

昔からある。たとえばコメントからドキュメントを生成するJavaDocのようなもの。

イメージが沸きにくかったので、PHPメンターズさんの公開されている 「Symfony2 ベースのサンプル」をお借りしてきて、ApiGenで、サンプルを生成してみました。

※日本語の部分は私が追記したコメントです。

(関係ないけれど、apigen、PEARでインストールしたら、そのままだと動かなかった。 手でエラーになる箇所のincludeパスを書き換えてやるか、composer install して使うかすればOKだった)。

ビルド系ツール(Grunt、Jenkins等)で自動生成させれば、手間なく吐けます。

UML的なもの

平鍋さんのアジャイルモデリングの記事に活用イメージが紹介されています。

※「php uml 自動生成」でぐぐって、doxygenを試してみたのですが、継承等はUML生成されるのですが、あるメソッドが別のクラスのオブジェクトを引数に取る、といった情報についての図示ができるツールではありませんでした。

「ドメイン」、「モデル」という用語について

3章の内容とは直接関係無いのですが、自分の中で混乱していた用語がやっと整理できたような気がするので以下にメモ。

ユーザが見ても理解可能なコアドメインのモデルと、そうではない、「実装のためのモデル」とがある。DDD本では後者は扱っていないのか?

(読書会を始めた当初の時期、私が会社で作っていたのは、 スケールを前提条件とした分散トランザクションの処理だった。 それは、ユーザ(ディレクタ = ドメインエキスパート)から見れば「ひとこと」であっさりと言えてしまう単純な機能であるにも関わらず、 裏側は非同期(メッセージキューイング)で、そこそこ複雑な構成のクラス群。 これは、DDD本で言うとどのあたりの話になるのかなと、気になっていた)。

ユーザでも理解可能なドメインモデルは、分かりやすく抽象化されているもので、私のイメージしている実装のためのモデルは、もっと具体的な、「解決ドメインのモデル」と言えそう。 この本が主題にしているのは、前者の、問題ドメインのドメイン知識から作るドメインモデルの方だと思う(たぶん。自信無し)。

“ユーザ(ディレクタ)から見れば「ひとこと」であっさりと言えてしまう”のであれば、 実装コード上も、そのまま「ひとこと」で済んでいるだけのI/Fが、ドメイン層のどこかに表現される。 スケールのための裏側のごちゃごちゃとした実装の仕掛け群については、オブジェクト指向の責務分割によって、別のクラスやパッケージに切り出す。 これによって、たとえば保守を担当することになった他のエンジニアが後から見ても、意味が把握できるシステムになる、という理解で良いのかなと思いました(自信なし)。

以上とは全く別な話として、「問題ドメイン」には、「ビジネスドメイン」と「技術ドメイン」とがある。 技術ドメインとして、思いつく例を挙げる。

  • Webアプリケーションフレームワークそのものを作っているエンジニアから見たWebアプリケーション
  • メッセージキューイングシステムそのものを作っているライブラリ作者から見たメッセージキューイング

Webチャットのように、リアルなモノではなく、電子データのやり取りが中心となるようなコンピュータドメインもある。

話は変わって、設計支援ツール「XEAD Modeler」をインストールしてみるところまでの話

ところで、最近「業務システムモデリング練習帳」を読んでいます。後半になってくると、私には難しくて、なかなか読破できません、笑。エンタープライズ向けの本ですが、Web系PHPerが読んでもおもしろい、実践的なトレーニングブック。モデル図もたくさん出てきます。

読書会では、著者の渡辺幸三さんの話題がたびたび出てくるので、読んでみたくなったのでした。

渡辺さんが作られている設計支援ツール、XEAD Modeler を Mac で動かして、販売管理のサンプルデータを開いて、おおっ、なんか凄い!と思ったりしました。 まだ記事に書けるほどの理解ができていないので、今後学習していきたいと思います。 (Macだと、右クリックのイベントが拾えていないような気がします。私の使い方が間違っているのだろうか)。

  • XEAD Modeler をMac で動かす手順メモ

https://github.com/xead/XeadModeler を git clone する。

Modeler.javaと Res_ja.java に日本語があるのであらかじめUTF-8に変換しておく。

EclipseでJavaプロジェクトを作成してインポートする。

poi-3.10-FINAL-20140208.jar xerces-2_10_0-xml-schema-1.1-beta jaxp-ri-1.4.jar

をWebから落としてきて、プロジェクトに追加し、右クリックでビルドパスを追加設定。 [Javaアプリケーション]として実行。

OSSなので、PullRequestもしました。面識のないフランス人にプルリクした時と同じくらい緊張しました。