CONCEPTUAL CONTOURS (p.260) †
要約 †
p260-1
- 柔軟な組み合わせにするために機能性を犠牲にしたり、複雑さをカプセルかするために大きな塊にして、簡略化しすぎることがあります。
p260-2
- モデルやデザインの要素を巨大な構造でまとめると、機能的には問題ないが、異なるコンセプトが混ざってしまうため、それを使用するクライアントにとって理解しにくくなることがある。
p260-3
- でも、クラスやメソッドを分割しすぎても、無意味に複雑になる。
p260-4
- 決まりきった規則は役に立たない。しかし、ほとんどのドメインには論理的な一貫性がある。これのお陰で、ドメインのいくつかの部品に適切なモデルを見つけるとき、後で発見する他の部品と一致する傾向があります。
p260-5
- これが、リファクタリングは柔軟性に通じると繰り返し言われる理由の一つです。コードが新たに概念や要件を理解するために適合させられるとき、CONCEPTUAL CONTOURSは現れます。
p260-6
- 高い凝集と疎結合の原理は、すべてのスケールでデザインに必要です。クラスとMODULESを通したやり方から大規模な構造まで。
p261-1
- 機能性の概念的に重要な単位を見つけてください。そうすれば、結果として起こるデザインは、柔軟性があり、理解できるようになるでしょう。
p261-2
- ソフトウェアが役立つ人々によって、詳細が興味のないドメインの領域の場合があります。
- 例えば、私たちが仮定している塗料混合アプリケーションのユーザは、赤や青の顔料を加えません。彼らは絵の具だけを混合します。(その絵の具には3個の顔料が含まれています)。
p261-3
p261-4
- あなたが考える、そのドメインの重要な区分の直観を考慮に入れて、デザイン要素(操作、インタフェース、クラス、およびAGGREGATES)を密接な単位に分解してください、
- 継続的なリファクタリングを通して変化と安定性の流れを観測してください、そして、これらのパターンについて説明する基本的なCONCEPTUAL CONTOURSを探してください。
- 知識を生かせるドメインの特徴に対して、矛盾のないモデルにしてください。
p261-5
- 目標は、UBIQUITOUS LANGUAGEで賢明な記述をするために論理的に統合されたシンプルなインタフェースのセットです。通常これは、深い洞察のもとに実施したリファクタリングで現れます。
p262-1
- デザインがCONCEPTUAL CONTOURSに従う時でさえ、変更とリファクタリングが必要です。
- 継続的なリファクタリングが局所化される傾向にあると、モデルに沿っている証拠です。
- オブジェクトやメソッドの問題で、広範囲の修正が必要な場面に直面すると言う事は、"私たちのドメインの理解に洗練が必要だ。"っと言うメッセージです。
Example
The CONTOURS of Accruals(見越額の輪郭)
p262-2
- 第9章で、ローントラッキング・システムは会計学のコンセプトに関する、より深い洞察に基づいてリファクタリングされました。
p263-1
- 新しいモデルは古いのよりひとつだけ余分にオブジェクトを含みましたが、責任分担が大きく改善した。
p263-2
- Caluculatorのクラスの場合を通して解決されたスケジュールは、料金と利子が異なったタイプのクラスに分割され、別々に保たれた料金と利子の支払いは、一括されました。
p263-3
- 新しい明白な概念とAccrual Scheduleの構造の凝集性が共鳴したおかげで、開発者は、このモデルがドメインのCONCEPTUAL CONTOURSのいくつかをやるのが良いと、信じていました。
p263-4
- 開発者が確信して予測した1つの変化は、新しいAccrual Schedulesを追加することでした。
- それで、既存の機能性をより明確でより簡単にすることに加えて、彼女は新しいスケジュールを紹介するのを簡単にするモデルを選びました。
- しかし、彼女はアプリケーションとビジネスが発展するのに応じて、ドメインデザインが変化して、成長するのを助けるCONCEPTUAL CONTOURSを見つけましたか?
- デザインがどう思いがけない変化を扱うかに関して保証が全くあったはずがありませんが、彼女は、可能性を改良したと考えました。
An Unanticipated Change
思いがけない変化
p263-5
- プロジェクトが続き、支払いが早いときと遅いときを扱うための詳細な規則に関する用件が浮上した。
- 彼女が問題を研究したとき、利子の支払いと、料金の支払いがほとんど同じ規則に見えたため、開発者は喜んだ。
- これは、新しいモデル要素が自然にただ一つのPaymentのクラスにつながることを意味しました。
p264-1
- 古いデザインは2つのPayment Historyクラスに複製を強制したでしょう。
- (この困難は、Paymentクラスが共有され、別の経路で同様のモデルに導くことの洞察の引き金となったかもしれません。)
* * *
p264-2
- INTENTION-REVEALING INTERFACESはクライアントにメカニズムよりむしろ意味の単位としてオブジェクトを提示させます。
- SIDE-EFFECTのFUNCTIONSとASSERTIONSは、それらのユニットを使用したり、複雑な組み合わせをするのを安全にします。
- CONCEPTUAL CONTOURSの出現で、モデルの部分を安定させて、ユニットを使用したり、結合するのがより直感的になります。
p264-3
- 相互依存性が私達に一度にたくさんのことを考えることを強制するとき、私たちはまだ概念的なオーバーロードを出くわすことがあります…
担当者のつぶやき †
- 英語難しいです。何を言いたいのか伝わってきません。これでいいのか・・・？
- 訳が直前になって申し訳ない。
みんなの突っ込み †
- 議論が抽象的なので難しいですね。"CONTOURS"って訳すなら「輪郭」でしょうか。ドメインモデルの中で「概念的にひとくくりにできるもの」をキチンと切り分けなさい、というのが本筋のようですよ。その上でポイントっぽいところを「輪郭」な感じを強調しながら訳すと少し分かりやすくなるかもしれません。
- p261-1
- 概念の上でも意味をなす「機能の単位」を見つけなさい。
- p261-4
- デザインの諸要素をしっかりと結合した単位に分解しなさい。その時考慮に入れるのは、ドメインの中で重要な境界がどう設定されているかということに対するあなたの直感です。-- 和智?
- 概念って境界線がもやもやしているけど、実は明確な輪郭が隠されている。リファクタリングしながら、それを掘り起こしなさい、というのがこのパターンの真意だと私は理解してます。これって、いわゆるオブジェクト指向の「高凝集性」をドメイン駆動的に言いかえたものだと思っています。 -- 佐藤?
