Domain-Driven Design の16章「構造」では、システム全体を、表現するテクニックとして、System Metapher パターンをあげている。
私は、メタファーテクニックは、賛成できないなあー。
エバンスも、
■ 使えるプロジェクトは、多くはない
■ メタファーは、しょせんは、本来のモデルではない借り物
■ メタファーを使う価値をプロジェクトの途中で、みなおすべき
■ メタファーの弊害に気が付いたら、メタファー利用を停止すべき
...
てな感じで、注意点を並べている。全体として、否定的なトーンを感じる。
DDD では、ネットワーク上の Fire Wall ソフトウェアを、System Metapher が役に立っている例としてあげている。
イメージはぴったりかもしれない。
業務のプロが、使っているメタファーは、そのままドメインモデル、ユビキタス言語として、もちろん取り入れるべき。
プロジェクト管理という問題領域だと、火を噴くとか、火消しとか、言いますね。これは、プロジェクト管理ソフトのメタファーとして有効かもしれない。
火事の種類、火事の進行状況、火災の通報、消化方法の種類、...
現実世界の火事をモデルにした、全体モデルをつくれそうだなあ。
もっとも、火を噴いたプロジェクトを管理するソフトウェアを造っても、だれも使わないとは思いますが...
業務のプロの言葉に注意深く耳を傾ければ、ちょっとしたメタファー(別のドメインの概念から借りてきた概念)を使っているケースは、それなりにありそう。
でも、業務全体(=システム全体)を、借り物の概念でとらえることは、ほとんどないと思う。
ほんとうに、ある業務全体イメージを、別の領域のモデルから借り物でやっているドメインでは、借り物の概念を、そのまま、ドメインモデルとして、ユビキタス言語に取り入れるべきでしょう。
ソフトウェアをはじめ、IT の世界は、実は借り物(メタファー)だらけなんですよね。
プログラム、アプリケーション、ビルド、ネットワーク、コンピュータ、...
コンピュータ登場前から、使われていた言葉ばかり。
プログラム=式次第
アプリケーション=申し込み用紙
ビルド=建築
ネットワーク=網細工
コンピュータ=勘定方
...
てな感じですね。
開発メンバーが、対象の問題領域が、ちんぷんかんぷんの時には、初心者向けのメタファーで、理解が早まるなら、使うのはあり。
サービスの提供( Service Delivery ) は、「物の出荷」(Shipment) と同じ、とかね。
おっと、「同じ」を使うと、メタファーじゃなくなっちゃうね。ルール違反。
○○の「ような」と使うのは、明喩。
メタファー(暗喩)というのは、「ような」抜きで、使うもの。
ソフトウェアのソースコードを「プログラム(式次第)」と言い切れば、りっぱなメタファー。
「プログラム(式次第)」の「ようなもの」と言えば、これは、明喩。
ようするに、メタファーというのは、本当は別の名前(概念)を、これが、そのものです、と言い切る言い方。
モデリングで使うのは、基本的には、まちがっている、というのが私の意見。
カタカナ言葉のメタファーは、絶対使うべきではない。
Firewall : アメリカ人のチームなら OK
ファイアウォール : 禁止!
防火壁 : まあ、よしとしましょうか。
複数の人が聞いたときに、イメージにばらつきがある言葉は、絶対にさけなきゃいけない。
カタカナ言葉で、メタファー(暗喩)を使ったら、10人いたら、10人のイメージはばらばらです。
ソフトウェアやITで、日本で、とんちんかんな理解をされている技術が多いのは、カタカナ言葉+メタファーという、最悪のパターンの言葉が氾濫していらからだと思っている。
実際に、私たちのチームでは、「カタカナ」禁止のモデリングをしているけど、明らかに、メンバー間の意識合わせには、有効です。
マッキントッシュのデザインでは、メタファーが積極的に使われたことが有名。
「ゴミ箱」なんていうメタファーは、なかかなしゃれていた。
でもねえ、フロッピディスクを、取り出すために、フロッピアイコンを「ゴミ箱」に移動する、というのは、ひどいデザイン。
最初、ディスクが初期化されてしまいそうで、怖くて、できなかった。
私は、この時のトラウマ(?)があるので、メタファーの危険や失敗は、声を大にして主張したい。
メタファー(暗喩)は、モデリングのテクニックとしては、まちがっている。使うべきではない。
私は、メタファーテクニックは、賛成できないなあー。
エバンスも、
■ 使えるプロジェクトは、多くはない
■ メタファーは、しょせんは、本来のモデルではない借り物
■ メタファーを使う価値をプロジェクトの途中で、みなおすべき
■ メタファーの弊害に気が付いたら、メタファー利用を停止すべき
...
てな感じで、注意点を並べている。全体として、否定的なトーンを感じる。
Fire Wall
DDD では、ネットワーク上の Fire Wall ソフトウェアを、System Metapher が役に立っている例としてあげている。
イメージはぴったりかもしれない。
使うべき時
業務のプロが、使っているメタファーは、そのままドメインモデル、ユビキタス言語として、もちろん取り入れるべき。
プロジェクト管理という問題領域だと、火を噴くとか、火消しとか、言いますね。これは、プロジェクト管理ソフトのメタファーとして有効かもしれない。
火事の種類、火事の進行状況、火災の通報、消化方法の種類、...
現実世界の火事をモデルにした、全体モデルをつくれそうだなあ。
もっとも、火を噴いたプロジェクトを管理するソフトウェアを造っても、だれも使わないとは思いますが...
業務のプロの言葉に注意深く耳を傾ければ、ちょっとしたメタファー(別のドメインの概念から借りてきた概念)を使っているケースは、それなりにありそう。
でも、業務全体(=システム全体)を、借り物の概念でとらえることは、ほとんどないと思う。
ほんとうに、ある業務全体イメージを、別の領域のモデルから借り物でやっているドメインでは、借り物の概念を、そのまま、ドメインモデルとして、ユビキタス言語に取り入れるべきでしょう。
ソフトウェアをはじめ、IT の世界は、実は借り物(メタファー)だらけなんですよね。
プログラム、アプリケーション、ビルド、ネットワーク、コンピュータ、...
コンピュータ登場前から、使われていた言葉ばかり。
プログラム=式次第
アプリケーション=申し込み用紙
ビルド=建築
ネットワーク=網細工
コンピュータ=勘定方
...
てな感じですね。
期間限定で使うべき時
開発メンバーが、対象の問題領域が、ちんぷんかんぷんの時には、初心者向けのメタファーで、理解が早まるなら、使うのはあり。
サービスの提供( Service Delivery ) は、「物の出荷」(Shipment) と同じ、とかね。
おっと、「同じ」を使うと、メタファーじゃなくなっちゃうね。ルール違反。
○○の「ような」と使うのは、明喩。
メタファー(暗喩)というのは、「ような」抜きで、使うもの。
ソフトウェアのソースコードを「プログラム(式次第)」と言い切れば、りっぱなメタファー。
「プログラム(式次第)」の「ようなもの」と言えば、これは、明喩。
ようするに、メタファーというのは、本当は別の名前(概念)を、これが、そのものです、と言い切る言い方。
モデリングで使うのは、基本的には、まちがっている、というのが私の意見。
絶対禁止:カタカナのメタファー
カタカナ言葉のメタファーは、絶対使うべきではない。
Firewall : アメリカ人のチームなら OK
ファイアウォール : 禁止!
防火壁 : まあ、よしとしましょうか。
複数の人が聞いたときに、イメージにばらつきがある言葉は、絶対にさけなきゃいけない。
カタカナ言葉で、メタファー(暗喩)を使ったら、10人いたら、10人のイメージはばらばらです。
ソフトウェアやITで、日本で、とんちんかんな理解をされている技術が多いのは、カタカナ言葉+メタファーという、最悪のパターンの言葉が氾濫していらからだと思っている。
実際に、私たちのチームでは、「カタカナ」禁止のモデリングをしているけど、明らかに、メンバー間の意識合わせには、有効です。
ゴミ箱
マッキントッシュのデザインでは、メタファーが積極的に使われたことが有名。
「ゴミ箱」なんていうメタファーは、なかかなしゃれていた。
でもねえ、フロッピディスクを、取り出すために、フロッピアイコンを「ゴミ箱」に移動する、というのは、ひどいデザイン。
最初、ディスクが初期化されてしまいそうで、怖くて、できなかった。
私は、この時のトラウマ(?)があるので、メタファーの危険や失敗は、声を大にして主張したい。
メタファー(暗喩)は、モデリングのテクニックとしては、まちがっている。使うべきではない。