DDDについて、だらだらと

ちょっと体調を崩しまして、病院にいってきたのですが（インフルエンザではない）、待ち時間が半端ないのはわかっていたので、Domain-Driven Design (DDD)を持って行きました。

Domain-Driven Design: Tackling Complexity in the Heart of Software

作者: Eric Evans
出版社/メーカー: Addison-Wesley Professional
発売日: 2003/08/22
メディア: ハードカバー
購入: 4人クリック: 113回
この商品を含むブログ (89件) を見る

MVC のネタを書いたときに、梅澤さんに

WebのMVCですが、Domain-Driven Designの言葉で語れば混乱は生じないと思うんですよね。

とコメントを頂いたのですが、DDDが積読状態なので「そうですよね〜」と言えないわたしは、あまりにワナビーすぎて、情けない。

DDD はいわゆるパターン本で、GoF でデザインパターンよりももっと大きなパターン――「設計(ドメインモデル)」のパターンと「設計をすること(モデリング)」自体のパターンを扱った本ですが・・・日本語訳がありませぬ。

わたしは本当に英語が苦手で、読もうとがんばっても直ぐに飽きてしまって別のことを始めてしまうか（ネットにつながった環境があったら5分ともたない）、眠ってしまうか(まるでのび太のように）なので、全然読めていませんでした。で、梅澤さんも貼ってくれたこちらのまとめサイト

Domain-Driven Designのエッセンス

と、要約本（日本語翻訳有り）の

Domain Driven Design（ドメイン駆動設計） Quickly 日本語版

を読んで満足してしまっていました。・・・これじゃ単なる技術書コレクタですよorz

このままじゃいけない！・・ということで、隔離されて退屈な病院の待合室ならば少しは読み進められるかな、と思い持ち出した次第です。結果はそこそこちゃんと読み進められて、満足でしたが、それでもまだまだ先は長いなぁ。コードがいっぱい書いてある本ならまだしも、こういう本で英語で500ページはわたしにとって「無茶しやがって」な買い物でした。しくしく

* * *

DDD は良いモノなので、読んでない方が読みたくなるようなエントリーを作りたいな、と思いました。（読了もしてないのに！）

そういうエントリはまだムリなので、今日は単にDDDを読みながら連想ゲームで思ったことを、つれづれと。（ネタがDDD前半(..というか1/3くらい)に集中してるのは、そこまでしか読めてないからです ...orz）

Hands-On Modeler パターンと Smart UI アンチパターン

DDD は JavaBlack さんがネタにしてなかったけな？と思ってみたのだけれど、探してみても見つかりませんでした。いよいよボケたかな、わたし。Hands-On Modeler とか Smart UI はいかにも JavaBlackさんがネタにしそうな話なので、脳内捏造が走ったようです。

リンクを貼りたいコンテンツが幻だったので、いつか書いてくれないかなぁと、どさくさにまぎれてリクエスト。

というわけで、この二つ。

● Hands-On Modeler（実践的モデラー）パターン
もしモデラーがプログラムを書けなかったり、プログラマがドメインモデルに興味を示さなかったら、MDDの利点であるモデリングとプログラミングの好循環は生まれない。また、チームのコミュニケーションもそこで停滞してしまう。MDDを通してユビキタス言語を実現するには、モデラーが動くプログラムを書けなければいけないし、同時にプログラマがドメインモデルを理解し、修正できなければならない。つまり、チームのすべての開発者は、プログラムを書くモデラーでなければならない。
[ 技術講座 ] Domain-Driven Designのエッセンス第1回｜オブジェクトの広場

これはプログラムの書けない SE(笑) の「モデリング」が全く役に立たない（実装できない）話。ドメインモデル貧血症とかにも繋がります。

わたしのエントリ現実の構造を分析し、それをプログラムの構造にそのまま写すのが何故いけないかは、もともとOOP が勉強途上な方の「モデリング」に関する質問に、「まずは OOP をやってみよう！」と答えたネタ（が膨張したもの）なのですが、書き方がへたくそすぎて、はてブで

tgk oo こういう考え方だと、オブジェクト指向設計とは実装のことを考えながら設計するということなのかな。OOの人はみんなそうなのかな 2009/04/27
thesecret3 モデリングって知識の記述なので、プログラムの方から出てきちゃだめなんでは。結果として定数しか提供しないとしても。 2009/04/27
はてなブックマーク - 現実の構造を分析し、それをプログラムの構造にそのまま写すのが何故いけないか - みねこあ

みたいな突っ込みが。この突っ込みの回答として、もう一歩進んで Hands-On Modelerに繋げれば面白いエントリーが書けたのかな？、と今更ながら思います。けれどはてブについては katzchang さんが超適切なコメント

katzchang 現実のモデルはプログラム設計の重要なヒントになるし、より良いプログラムを書けるということは、よりよい現実のモデルが出来たと同義だと思うけれども。 2009/04/26
はてなブックマーク - 現実の構造を分析し、それをプログラムの構造にそのまま写すのが何故いけないか - みねこあ

でそのものをフォロー済みなので、本当に今更です。しくしく。

もうひとつ、ネタになりそうなのは Smart UI アンチパターン

● Smart UI（利口なUI）アンチパターン
層状アーキテクチャの対極をなすアンチパターン。ビジネスロジックやデータアクセスのコードが、UIのコードと一緒になってしまっている、いわばスパゲッティな状態。利口なUIと呼ぶのは、ビジネスロジックを含むすべての処理がUIの中で行なわれるから。最もやっつけで手軽なやり方がこれなので、設計を何も考ないとこの状態に陥ってしまう。開発チームのスキルが低くて、かついわゆる第4世代（4GL）と呼ばれるようなグラフィカルな開発ツールを最大限に利用する場合は、このパターンの採用にも一理ある。しかし、利口なUIを採用してしまうとMDDが一切機能しなくなるので、DDDは諦めるしかない。
[ 技術講座 ] Domain-Driven Designのエッセンス第2回｜オブジェクトの広場

PHP なんかがこのアンチパターンに直球ですね。このアンチパターンは、火消しで現場入りすることが多かったわたしには個人的な恨み募りまくりのもので、初心者向けと素人向けや素人が素人のまま仕事を出来てしまうなんかで夏音ばりの黒いオーラ出しまくりのエントリーをつくってます。

が、「このパターンにも一理ある」というのが難しいところ(よく田辺さんにコメントでつっこまれるポイントです)。わたしはプロなら一理あっちゃいけないと思うのですが、そこらへんは意見が分かれるところだと思います。

Layered Architectureとか

Layered Architecture と、 Chapter 5「A Model Expressed in Software」やChapter 6「The Life Cycle of a Domain Object」　で紹介されているパターン

Entities
Value Object
Service
Module
Aggregates
Factories
Repositories

あたりは、誰もが名前や概念を何処かで（何かの伝聞や、標準のクラスライブラリ、フレームワーク、関わったプロジェクトの設計 etc）で、一度は目にしたことがあるモノだと思いますが、結構曖昧な理解になっていたり、メリット・デメリットが頭の中でよく整理できていなかったりしがちです・・・というか、わたしがそうです(^^;

ここら辺の概念の整理や用語の統一はパターン本の真骨頂。みんなに読まれてナンボの世界なので、日本語訳本でないかなぁ、と思ったりする次第。

Pluggable Component Framework

「DDDの最終形態」「DDDの桃源郷」といわれる Pluggable Component Framework。

わたしのお仕事は「フレームワークの作成」が多いのですが、正直失敗ばかりです。難しいですね。

● Pluggable Component Framework（着脱可能コンポーネントのフレームワーク）パターン
あるドメインで何度かDDDを成功させ、ドメインへの深い理解へと到達していくと、そのドメインに特化したドメインフレームワークを設計できることがある。ドメインフレームワークとは、中核の抽象化により抽出されたドメインの中心的なインタフェースと相互作用から構成される中央ハブのようなもので、そこにドメインの可変部分をコンポーネントとして着脱できる。ただし、ドメインフレームワークには、(1) 実現が非常に難しい、(2) フレームワークが提供する中核ドメインにアプリケーションが縛られる、などの欠点もある。
[ 技術講座 ] Domain-Driven Designのエッセンス第3回｜オブジェクトの広場

ウォーターフォール開発が失敗しやすいのはまさにここで、「部品の再利用」を追求し無自覚のままこの究極のフレームワークを要求しているのに、「ドメインへの深い理解」を得られない開発の初期にそれを作ることを要求するから・・と言うのがあると思います。

このような場合、引用部(2) の欠点はよく具体開発チームからクレームとしてあがってくるけれど、その修正は非常に大変（修正に対して開いていて拡張に対して閉じてるんだもん）。

そしてウォータフォール開発では、「戻り」の多いフレームワーク設計の修正は「ミス」として、「原因究明と再発防止のため」の「始末書もどき」を書かされるようなケースも少なくない現状です。そういうときは「まだコピペのほうが『始末』の数は少なくてすみますし、比較的幸せになれますよ！（顧客以外）」と、胸の中で暴言を言ってしまうのが人情というもの。

だからこういう風に「ずっとその業務の開発に関わっているとかしないと、普通成功しないよ」と言ってくれるのは、「そうなんだよね！ね！」と嬉しくなってしまうわたしです。

ただ、こういうのに挑戦するのはとても愉しいので、止められないのですよね。

特に今作って使われているのは、組み込みなのでそれほど規模も大きくないこととン年越しで業務にかかわってドメインをよく理解して作ったモノ(いわゆるVer.2)なので、そこそこ上手くいっています。追加仕様や新規仕様が「こんなこともあろうかと」機構にピタリと填ると、ひとりでニンマリしてます。

そういう意味で、Ver.2 造りってとっても愉しいですよね。