Java EE勉強会

DDD / GENERIC SUBDOMAINS

DDD

GENERIC SUBDOMAINS (p.406) †

要約 †

GENERIC SUBDOMAINS
＊＊＊

[問題についての説明]

  • モデルのある部分は、特殊な知識の習得や伝達なしに複雑さを追加する。
  • 異物はCORE DOMAINの理解を難しくする。
  • そのようなモデルは皆が知っている一般的な真理を塞ぎ、優先度の低い特殊な分野に詳しいものとなる。
  • 塞がれた要素は、システムが機能する為、モデルを完全に表現する為に必須である。

問題サマリ

[問題の解決方法についての説明]

  • モデルの中には「当たり前」と扱いたい部分がある。
  • しばしば、ドメイン周辺に多大な努力を費やされる事がある。
  • 時間やタイムゾーンの再設計に優秀な開発者割り当てられてていたプロジェクトもあった
  • 時間やタイムゾーンのようなコンポーネントは動かなければいけないが、一方でCOREシステムのコンセプトではない。
  • 全ての相関要素と共にCOREが融合されると、generic model elementがその責務を果たす事は非常に難しくなってくる。

Therefore:

  • プロジェクトにとって重要でないが、結合度の強いサブドメインを特定しなさい
  • サブドメイン間のgeneric　modelを抽出し、別MODULEとして切り出しなさい。
  • MODULEとして切り出したら、CORE DOMAINより低い優先度で開発を続けなさい。
  • 以後、中心メンバーを割り当てる事は避けなさい。
  • これらGENERIC SUBDOMAINの為に、Off-the-Sheld Solutionやモデルの公開も考慮しなさい。

解決方法サマリ

Option1：Off-the-Sheld Solution (実装の購入、オープンソースコードの利用) †

p407-1段落（Disadvantagesの後）

  • Off-the-shelf Solutionには調査が必要だが、大抵は徒労に終わらない。
  • しばしば、GENERIC SUBDOMAIN solutions はフレームワークの中に内包されている。
  • その場合は非常に抽象的なモデルとして実装されており、自分達のアプリケーションへの統合や特殊化する事も可能である。

長所 †

  • 少ないコード
  • 外面化されるメンテナンス負荷
  • より洗練されたコードで、様々な場面で使用されたと考えられる為、自前のコードよりもより強固で完全

短所 †

  • 評価と学習に費やす時間を費やさねばならない
  • 自分達の産業にあわせた品質管理
  • 自前の実装時より、目的にあわせた統合にはより工数がかかるかもしれない。
  • 通常、外的要因の存在は、スムーズな統合を妨げる。
    商用コードや、オープンソースには独自の BOUND CONTEXT が存在するだろう。例え存在しなくても、自分達のパッケージからそれらの ENTITIES を円滑に参照する事は難しいだろう。

Option2:A Published Design or Model †

p408-1段落（Disadvantagesの後）

  • Domain Modering 取り分け、Generic　Subdomainに取りかかっている場合は Tom Lehreeの盗用！、盗用！は良い助言だ。
  • Analysis Patterns（Fowler 1996）のような、広く普及しているモデルを使う場合に最高の効果が得られる。
  • とても堅固で合理的なだけでなく、人々に広く理解されており、プレゼンや学習の負荷を減らしてくれる。（10章 参照）
  • 要件を満たす単純かつ自己完結したsubsetを見つける事が出来たら、published model の全てを無理に実装しようと思ってはいけない。

長所 †

  • 多くの人々の洞察を反映しており、自前の実装よりも洗練されている。
  • 高い品質のドキュメントが直ぐに手に入る。

短所 †

  • 自分達の要求に、ぴったり当てはまらないかもしれない。
  • 要求に合わせるには、より工数が必要になるかもしれない。

Option3:An Outsourced Implementation †

p409-1段落（Disadvantagesの後）

  • 自動テストは Outsourced Implementation において重要な役割を果たす。
  • 実装者は提供したコードを単体テストの求められるべきである。
  • 本当に強力なアプローチは明確にする事、OUTSOURCEされたコンポーネント用の自動化された受け入れテストの書く事である。
  • OUTSOURCEされた実装は published design or modelとも素晴らしく相性が良い。

長所 †

  • チームをCORE DOMAIN に専念させてくれる。
  • 常に大きなチームを形成する事も、CORE DOMAINの知識を無駄に分散する事もなく、より多くの開発が行える。
  • インタフェース志向の設計を強制できる。そして、仕様は外部に投げているのでsubdomain を generic な状態に留める事を助長する。

短所 †

  • インタフェースやコーディング規約等の重要なものに対してコミュニケーションが必要な為、依然としてcoreチームは時間を要求される。
  • コードは理解されなければいけない為、翻訳に多大なオーバーヘッド（負荷は少なくなっているといっても）を費やす。
  • コードの品質が均一でない。

Option4:An In House Implementation †

長所 †

  • 統合が簡単。
  • 欲しいものだけ手に入れられる。
  • 一時的な契約者を割り当てられる。

欠点 †

  • 進行中のメンテナンス、トレーニングの負荷
  • 時間や費用に関して楽観的な見積もりになりやすい

A Tale of Two Time Zones †

TimeとTimeZone?の格納と変換に最も優秀な開発者を数週間割り当てた2つの対照的なプロジェクト（Cargo ShippingとInsuranceのプロジェクト）の例を徒然と・・・

  • 最初のプロジェクトは貨物船のスケジューリングソフトの設計であった。
  • 国際化された輸送スケジュールを組む為に、TimeとTimeZone?への対応は必須であった。
  • この機能への重要性が認知された時、チームはCORE DOMAIN の設計とtimeクラスとダミーデータを使用したアプリケーションの初期iterationに取り掛かっていた。
  • アプリケーションが洗練され始めるにつれて、既存のtimeクラスが相応しいものではないものである事が明らかになっていった。
  • 問題は日付表記の多様性に起因する非常に入り組んだものであった。
  • 彼等はoff-the-shelf solutionを模索したが、見つける事はできなかった。
  • 調査と的確なエンジニアを必要とする事になり、チームリーダーは彼らの中で最高のプログラマーを割り当てた。
  • しかし、この作業は特殊な業務知識を必要とする事も、業務知識への掘り下げる事もなかった。
  • その為、彼等は一時的に契約したプログラマーを割り当てたのである。
  • このプログラマーはゼロから作業を始めなかった。
  • 彼はいくつかの現存するtime　zoneのコードを調査した。
  • コードの殆どは要求にあうものではなかった為、BSD UNIXからpublic-domainを適用しCOREとの統合を実現した。
    （C言語で実装された精巧なデータベースからロジックをリバースエンジニアリングしたり、処理手順をインポート）
  • もう一方は保険会社向けの新規の保険料請求システムであり、さまざまな出来事（車の損傷、雹による天災など）の時間を取得する事を考えていた。
  • 情報は現地時間で記録される為、time zone に関する機能が必要とされた。
  • Evansが到着した時には、年少だが、非常に頭の良いの開発者が割り当てられていた。
  • 何が必要とされているかは曖昧な為、機能は柔軟であらゆる場面に十分対応すべきであると仮定された。
  • このような難しい問題には助けが必要とされたので、シニア・ディベロッパーもアサインされた。
  • 彼等は複雑なコードを書いたが、プロジェクトが頓挫した為、使われる事は無かった。
  • time zones に費やした労力がCORE DOMAINへ向けれれていたら、彼等はこの機能の雛形を世に送り出していただろう。
  • 両プロジェクトが行った正しい事の１つは、CORE MODELから、GENERIC なtime zone として分離した事である。
  • 分離しなければ、COREはtime zones に関して不要な詳細を保持する為、理解が難しくなるし、モジュールとして切り出しても、COREとの関連性が理解する必要がある為、メンテナンスが難しくなる。

　


Generic Doesn't Mean Reusable †

  • ここまで、サブドメインの generic の品質に強調してきた一方で、コードの再利用に関しては言及してきていない事に注意してください。
  • これは、出来る限りCORE DOMAINに力を注ぐべきで、GENERIC SUBDOMAINの開発は必要なときだけにすべきという事に反しています。
  • コードの再利用は起こりえますが、前提ではありません。
  • published design、modelを使用した時、再利用はしばしば有効です。
  • もし自分でモデルを作らねばならなければ、再利用は後の関係するプロジェクトにとって価値があるものとなるでしょう。
  • しかし、そのようなモデルの概念は多くの場面で適用できる一方で、generalityなモデルとして開発する必要はなかったと言えるでしょう。
  • 再利用可能なデザインは滅多にすべきものではないが、generic な概念に留まり続ける事に関しては厳格でなければならない。
  • 特定の産業モデルに、概念の一部でないものをデザインに持ち込むと、拡張を非常に難しいものにしてしまいます。
    （拡張には、完全に古いシステムを再構築したり、それを使用する他のモジュールの再設計が必要になるでしょう。）
  • 特定の産業の概念はCORE DOMAIN か自分自身に属している為、genericとするよりも特化されたサブドメイン、特化されたモデルがである方が価値がある。

Project Risk Management †

  • アジャイルプロセスは最も危険の大きいタスクを早期に取り組む事で、リスク管理を 行う事を要求している。
  • 特にXPでは早急にシステムを動かし、徹底的に調べ上げる事を推奨している。
  • しばしば、初期のシステムは、技術的な構造を証明し、解析の容易さからGeneric Subdomain をサポートするよりも周辺システムを構築する方に意識を向けさせる。
  • しかし、注意しなけさい。この欲望はリスク管理の目的から十分に逸脱する可能性がある。
＊＊＊
  • この章では、CORE DOMAIN を蒸留する為に、どのようにモデルとコードを変化させるべきかを示している。
  • しかしながら、p415以降の DOMAIN VISION STATEMENT と HIGHLIGHTED CORE の２つのパターンは補足的なドキュメントの利用方法について示している。

担当者のつぶやき †

  • GENERIC　SUBDOMAINを「DOMAIN」として扱うか？「インフラストラクチャ層などの共通機能」とするか迷いそう。
    「A Tale of Two Time Zone」を読んでいると、要はGENERIC　SUBDOMAINの開発はドメインに明るい主要メンバではなく、一時的に雇った人に任せろって言われているみたいで悲しい・・・ｗｗ
  • p406-4段落目　「Even if such a generic ・・・」以下が上手く訳せません。
    恐らく、例え「generic model element」の重要性は認識されていても、CORE　DOMAINの方がより重要であり、最善ではあっても最高ではないモデルになりがちで、COREが融合されると gneneric　modelの責務を果たす事は難しくなるみたいな事を言っているのでしょうか？
  • アウトソーシングって国内にしろ、海外に出すにしろ、コミュニケーション負荷が高すぎて（費用じゃなく品質的に）成功しているっていう話は聞かないんですが・・・
  • In-House Implementation」ってなんでしょう？社内システム部門で実装？ だとしとしても長所や欠点の理由がイメージできない。
fileWhat is the definition of in-house implementation?
Strictly speaking, in-house implementation means something done within a 
business or organization. The opposite of out-sourced.

This can be in reference to a task or group of tasks directly involved with
the primary business of a company or any secondary or support job that the
company must do.

In-house implementation means that an employee (or a number of employees) 
will do the job. Out-sourced means that the business will hire another
business to have their employees do the task.

　

みんなの突っ込み †


Menu