DDD/Declarative Design - Java EE勉強会

宣言的設計 (271) †

(ASSERTIONS can lead to...)
- アサーションは、比較的インフォーマルなやり方でテストを行ったとしても、よりよいデザインに導くが、手書きのソフトには何の保証もない。アサーションを避けると、コードは、除外できないさらなる副作用を持つ可能性がある。
- また、私たちは、何の意味のない決まり文句のようなコードを書くのに多くの時間を費やしている。これは退屈であり、エラーに満ちていて、それらが大量にあるとモデルの意味を曖昧にしてしまう。
- いくつかの言語は優れているが、それでも退屈な作業が必要だ。
- INTENTION-REVEALING INTERFACESや他のパターンは助けになるが、規約によるオブジェクト指向プログラミングに形式的な正確性を与えてはくれない。

(These are some of the motivations...)
- これらが宣言的設計の動機である。この用語は人によって意味が異なるが、通常は、一種の実行可能な仕様のプログラム書き方あるいはプログラムの一部を指す。
- 非常に正確なプロパティの記述がソフトウエアをコントロールする。リフレクションのメカニズムやコード自動生成を通じて、様々な形で行われる。
- このアプローチによって、開発者は最初に宣言に直面することができ、またこれには絶対的な保証がある。

(Generating a running program..)
- モデル・プロパティの宣言から実行可能なコードを生成することは、モデル駆動設計の究極の目的だ。しかし実際にはいくつか欠点がある。
- 例えば、
  - ・宣言記述言語の表現が不十分で、フレームワークは自動化された部分の拡張を非常に困難にする。
  - ・コード自動生成後に、手でコードを追加した場合、その後の再自動生成は破滅的になる。

(The unintended consequence...)
- 宣言的設計での意図しない結果は、開発者がフレームワークの限界に突き当たって、モデルとアプリケーションのレベルを落とすことだ。
- ルールベースのプログラミングは、また別の有望な宣言的設計の方法である。しかし微妙な問題がこの意図を崩しかねない。
- 多くのシステムでは、制御述語がパフォーマンスチューニングのために追加されており、それが副作用を持ち、結果として宣言されたルールとかけ離れたものとなる。ルールを追加・削除・並べ替えすることは、予期できない、不正確な結果をもたらす。そのため、論理型言語プログラマは、オブジェクト指向プログラマ同様、コードの副作用について注意する必要がある。

宣言的プログラミングの恩恵を受けるには、フレームワークのルールに従う必要がある。
最も価値があるといえるのは、パーシステンスやORマッピングなど、退屈でエラーが置きやすい設計の一面で、フレームワークが自動化して、開発者を厄介な作業から解放してくれることだ。

(An interesting approach...)
- 宣言的なアプローチがしばしばDSLであるのは興味深い。この方式では、特定のドメインの特定のモデルに合った言語で、クライアントコードは記述される。例えば、輸送システム用の言語は、貨物やルートなどの用語を、それらを結びつける文法とともに含むだろう。プログラムはオブジェクト指向言語などへとコンパイルされるが、ライブラリのクラスがそれらの用語のための実装を提供する。

このような言語では、プログラムは非常に表現力があり、ユビキタス言語と強い関連を持つ。これはワクワクする概念だが、DSLは、オブジェクト指向技術の中において欠点もある。

(To refine the model..)
- モデルを洗練するために、開発者は言語を修正できる必要がある。これには、文法や他の言語翻訳の特徴を含む。しかしそのためには、チームや将来のメンテナンスチームのスキルを考慮する必要がある。またアプリケーションとモデルが同じ言語で実装されているのは望ましいことだ。
- 他の欠点としては、クライアントコードを、改訂されたモデルと、それに結びついたドメイン特有言語に合わせてリファクタリングすることが難しいことだ。もちろんこのリファクタリングの問題に対して技術的な修正ができる人もいるだろうが。

From the Ground Up（土台から（？））

異なったパラダイムはDSLを、オブジェクトよりもよく扱うかもしれない。
関数言語の代表格であるScheme言語では、システムを分岐させることなく、
DLSを作ることができる。

このような技術は成熟したモデルに対しては最も有効であるが、そういう時には大抵クライアントのコードは別のチームによって書かれる。一般的にこのような設定は"技術力のあるフレームワーク開発者"と"技術力のないアプリケーション開発者"という有害な区別を産み出してしまいがちだが、そういう必然性があるわけではない。

非常に重要な部分ですね・・・細かい所を二箇所だけ
第二段落の最初の文は第一段落を受けて「これらが宣言的設計の動機である」です。
最後から二番目の段落（要約では最後の段落）は意味が逆転してしまっています。「このような技術は成熟したモデルに対しては最も有効であるが、そういう時には大抵クライアントのコードは別のチームによって書かれる。一般的にこのような設定は"技術力のあるフレームワーク開発者"と"技術力のないアプリケーション開発者"という有害な区別を産み出してしまいがちだが、そういう必然性があるわけではない。」-- 和智? 2008-12-21 (日) 10:40:04
なんでこれはパターンにしなかったんでしょうか？　DECLARATIVE DESIGNみたいな。パターンにするには、普遍的な概念すぎるから？ -- 佐藤? 2008-12-21 (日) 11:04:36
和智さん、指摘ありがとうございました。修正しておきました。あと、ドメイン特有言語とするのは訳しすぎだったので、DSLに直しました。 -- 塚田? 2009-01-22 (木) 23:29:46