エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

4.19
  • (32)
  • (26)
  • (11)
  • (2)
  • (1)
本棚登録 : 612
レビュー : 19
制作 : 今関 剛  和智 右桂  牧野 祐子 
zerobaseさん ソフトウェア   読み終わった 

面白い。久しぶりにソフトウェア工学の本を面白いと思った。90年代に『実践UML』を読んで以来。これはITアーキテクトではなくIAの視点でも面白い。

読みやすい構成、読みやすいデザイン。太字強調や細かい見出し設定のおかげでさくさく読める。パターン・ランゲージで書かれている。

当初は「これはIAの役に立つ手法だが、IA自身が勉強すべきことではない。エンジニアがIAや顧客(ドメインエキスパート)の言葉でモデリングできるようになればいいだけだ」と考えていた。

しかし、それはもったいない考え方だった。以下の文章で示されるような「オブジェクト指向UI (OOUI)」の発想からDDDを捉えるとどうだろう。そこにはドメインエキスパートとエンジニアの間で、IAやUIデザイナ自身もまたDDDを活用してモデリングしているという未来像が想像できないだろうか。

> GUI とオブジェクト指向の間には強い繋がりがあると確信していた僕でしたが、その関係性をもっと直接説明した資料はないかと思って調べたところ、それほど多くはないものの、いくつかの文献に行き当たりました。
> 合理的ではあるものの、操作方法がなんだかとても「手続的」で、機能要件をそのままコントロールに割り当てただけのような感じがするのです。結局、タスク指向に引き寄せられているのです。
> 考えてみればそれもそのはずで、OOA でモデル化されるのはあくまでもユーザーの要求事項と因果関係だけなので、それらを秩序だったひとつの道具としてまとめる世界観は、ユーザーの想像の域を出ないのです。これは決定的な弱点です。
> OOUI | Modeless and Modal http://modelessdesign.com/modelessandmodal/2009/10/29/ooui/

> 複雑性は減らすことができないわけですから、操作性を高めるためには、複雑性の一部をユーザーサイドからシステムサイドに移動してやる必要があります。
> どのように操作しても、左右のオブジェクトが常にイコールになるようになっており、「入力内容をメモリにバッファしてサブミットする」というシーケンシャルなフローを排除することに成功しています。もはやそこでは、「通貨を換算する」というタスクはデザインに対して拘束力を持たず、「左右のオブジェクトが互いにイコールになろうとする」というオブジェクト同士の静的な性質があるだけです。ユーザーはその性質を利用しながら自由な方法で目的を達成できるのです。
> ほとんどの設計者は、明文化された要件の中から「必要な入出力情報」を抽出し、それを「操作の手順」としてリニアライズしようとしてしまいます。その結果出来上がるのは「穴埋め式」のようなミニウィザードです。しかしUIをモードレスにするためには、「必要な入出力情報」を抽出した後は、「複雑性」の一部をシステムサイドに移動するような「オブジェクトの性質」を検討しなければならないのです。
> 要求全体をひとつのシンプルな世界観にまとめるためには、このような「要件として明文化はされていないけど出来てしまう事」を出来なくする方が難しいのです。これはむしろ、要件が持っていた「いびつさ」をデザインが矯正したと言えます。要件に対して過不足の全く無いデザインを無理に作っても、シンプルな世界観に落とし込めないのなら、それはユーザーにとっても理解しづらいものである可能性が高いのです。多少要件を拡大解釈することになっても、この模範回答のように、それによってデザインをシンプルかつ合理的にできるのであれば、そうするべきなのです。結果的に、画面数は1になっているのです。
> 複雑性をシステムサイドに移動させるには、UIをモードレスにして、「タスク選択」という課税的な操作を「オブジェクト選択」の操作に同化させてしまうのが有効です。そのためには、明文化された要求事項から「タスクの手順」を探るのではなく、「オブジェクトの性質」を探らなければならないのです。そして、出来上がったデザインが事前に定義した要件と異なるスコープを持っていたとしても、結果的にそれが役立つなら、それを受容するべきなのです。何かをデザインとは、そういうことではないでしょうか。
> Complexity | Modeless and Modal http://modelessdesign.com/modelessandmodal/2009/12/22/complexity/

> このような、「一応便利に使えはするけどイマイチなデザイン」について、僕はどのように評価すればよいのか迷います。ただ、それが目指すべき理想のデザインでないことは確かです。
> 問題は恐らく、UCD/HCD のメソッドが、RUP と同様に、ユーザーのタスク(業務)を拠り所としていることにあります。ユーザーの要求を知ろうとすることは確かにシステムの有効性を高めるために必要だと思いますが、ユーザー(コンテクスト)の多様性を考えると、タスクをベースにしてデザインされたシステムは、モーダルで非効率で学習しづらいものになってしまうのです。
> そのようなタスク指向のデザインメソッドに対するカウンターパートとして、OVID に代表されるオブジェクト指向デザインのプロセスがあります。
> オブジェクト指向デザインのメソッドでは、OOA/OOD で行うオブジェクト分析の結果を流用できます。すなわち、ユーザーの関心の対象であるオブジェクトをクラスとして定義し、それをそのままスクリーンに登場させるのです。またその結果として、モデル層のオブジェクトとビュー層のオブジェクトが比較的自然に対応するようになり、アルゴリズムの見通しも良くなるはずです。
> プログラム設計のためのクラス定義では、ユーザーのメンタルモデルには関係しないような抽象度の高いクラスやコントローラーのためのクラスなどが必要ですが、OOUI ではそれらは無視して、ユーザーにとって意味のあるクラスだけをUI上のオブジェクトとして表現します。
> 開発メソッドにおいてオブジェクト分析の手法が確立されているのに、それがUIに適用されていないのは、RUP に代表される標準的プロセスがタスク指向であるからだと前に書きました。しかしタスクを包括してクラスの性質を定義するというロジックの飛躍を許容するならば、モードレスなデザインもある程度メソッド化することが可能だろうと思います。その飛躍部分をノウハウとして整理するのが、デザインパターンの役割というわけです。
> UIを通じて「ユーザーが行えること」を決定するのはオブジェクトのクラスであり、その性質(プロパティとメソッド)です。つまりユーザーが接するクラスの性質を定義することが OOUI デザインの中心的作業になります。
> Counterpart | Modeless and Modal http://modelessdesign.com/modelessandmodal/2010/01/05/counterpart/


追記:2013年2月12日 再読完了。

p.12 永続化もUIもない、ドメインだけのコード。テスト駆動で。
コードに、ドメインエキスパートと開発者が共有するモデルが反映される。
動くコードによって、ドメインエキスパートとの議論が活発になる。

→いきなりウォーキングスケルトンとエンドツーエンドテストから書き始めるより、最初はドメイン層だけをテスト駆動開発することでドメイン言語を成長させた方が良いと思った。ドメイン知識が足りない時にアーキテクチャ全体を固定すること自体がBDUFな気が。

p.470 責務のレイヤー
- 意思決定支援
- ポリシー
- 確約
- 業務
- 潜在能力

> システムのそういう部分(※引用注:技術的なインフラストラクチャや、特別なドメインの知識がなくても理解可能な、うまく限定できるドメインに関する問題)は、コンピュータ科学者の関心を引くらしく、**他でも使える専門スキルを構築して、履歴書を書く時のいい材料になると考えられている**。特化したコアは、アプリケーションを実際に差別化してビジネスの資産とするようなモデルの部分であるのに、それほどスキルのない開発者によってまとめられることになるのが通例である。そういう開発者は**データベース管理者と協力してデータスキーマを作成し、モデルの持つ概念の力を一切利用することなく1機能ずつコードを書く**。(p.408-409)

> 純粋に技術的な課題は、通常、才能のあるソフトウェアエンジニアにとって最も興味深くやりがいがあるように見えるものだが、ドメイン駆動設計によって開かれる新しい挑戦の領域は、少なくともそれに匹敵する。ビジネスソフトウェアを作るのに、混沌としたものをボルトでつなぎ合わせるようにする必要はない。**複雑なドメインと格闘して、わかりやすいソフトウェア設計にすることは、優秀な技術者にとって刺激的な挑戦なのだ。**(p.511)

レビュー投稿日
2011年10月21日
読了日
2011年10月22日
本棚登録日
2011年10月21日
0
ツイートする
このエントリーをはてなブックマークに追加

『エリック・エヴァンスのドメイン駆動設計 ...』のレビューをもっとみる

『エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)』のレビューへのコメント

まだコメントはありません。

コメントをする場合は、ログインしてください。
ツイートする