DDD
SEPARATE WAYS (p.371-373) †
要約 †
SEPARATE WAYS （分離法）
【文脈の説明】
- 私たちは妥協なく要件をよく見なければならない。
- 必須でない関連を持つ２つの機能の集合を切り離すことができる。
＊＊＊
【問題サマリ】
【問題の解決方法についての説明】
- チームを調整するコストに加えて、統合は妥協を余儀なくさせる。
特別な需要に特化したモデルは、すべての状況を扱えるより抽象的なモデルに取って代わらなければならない。
もしかすると全然別の技術が簡単に提供してしまうかもしれないが、統合は難しい。
他のチームと協調しようとしても、何とかやっていくことが大変で、何をやっても駄目なこと必至。
- 大抵、統合は大きな利益を生まない。
2つの機能がお互いの機能性を呼びもせず、両方が触るオブジェクト間で相互作用もせず、操作中にデータを共有もしないなら、統合は翻訳のレイヤーを通すことも必要ないかもしれない。
特徴がユースケースで関連していても、統合が必要なわけではない。
Therefore:
【解決方法サマリ】
- 開発者が小さな範囲で特化したソリューションを簡単に探し出すことを許容して、BOUNDED CONTEXTが他のものには接続しないと断じよう。
- 特徴はミドルウェアかUI層で整理されるが、ロジックの共有はされず、翻訳のレイヤーを通してデータの絶対最小値を転送する。できれば無しに。
Example 保険プロジェクトのスリム化 †
- すべての顧客サービス代理業者と損害賠償解決係員が必要とする保険金請求のための、1つのシステムに統合された新しいソフトウェアを開発し始めた。
1年間努力したが、チームメンバーはお手上げ状態。
分析麻痺と、インフラの素晴らしい先行投資のコンボで、次第にイライラした管理が見えだした。
ガチで、彼らのどうにかしようとしている範囲は圧倒的だった。
- 新しいプロマネは、新しいプランを作る為、1週間、皆を部屋に閉じ込めた。
最初に彼らは要件のリストを作り、それらの難しさを見積もって重要性を割り当てようとした。
彼らは容赦なく難しさと重要でない方をぶつ切りにし、残ったリストに順番を決め始めた。
多くの洗練された決定がなされたが、重要なのは１つだけであると判明した。
いくつかの機能に対して、統合が少ししか価値を高めなかったことが認められた。
例えば、調整者は既存のデータベースへのアクセスを必要としたが、彼らの今のアクセスはとても不便だった。
しかし、ユーザはこのデータを必要としたが、提案されたシステムの他の機能はそれを使わないだろう。
- チームメンバーは簡単にアクセスする色々な方法を提案した。
あるケースでは、主要レポートをHTMLにエクスポートしてイントラネットに置いた。
他では、標準のソフトウェアパッケージを使用して書かれた特化したクエリーを調整者に提供した。
これらが、体系化したイントラネットページのリンクか、ユーザのデスクトップに置いたボタンで、統合されるかもしれない。
- チームは、同じメニューから始めるよりも、統合しないようにした小さいプロジェクトを始めた。
いくつもの有益な能力がほぼ夜通し提供された。
要件の集りを蒸留して無関係な機能の重荷を落としたメインアプリケーションの提供を期待する。
- そのように行けたかもしれないが、残念ながらチームは昔の習慣に戻り、再び自らを麻痺させた。
結局、小さなアプリケーションはレガシーで終わり、SEPARATE WAYSは消え去った。
＊＊＊
- SEPARATE WAYSを選択すると、いくつかのオプションが除外される。
- 継続的なリファクタリングはどんな決定も元に戻せるが、完全に分離して開発したモデルをマージするのは難しい。
- それでも統合が必要であるなら、翻訳のレイヤーは必需品ありcomplexである。
- もちろん、どのみち直面する問題である。
- 今、より大きな協調関係に戻り、肥大化した統合への対処法を考えよう…
担当者のつぶやき †
- 統合が難しいというより、統合（しようと）しちゃったシステムを分離することが難しいよ、って話なんですかね。いまいち例が理解できませんでしたが。。
みんなの突っ込み †
