DDD
変換（p389〜） †
要約 †
p389
- 一般的に、CONTEXTを分解するのはとても簡単であるが、併合したり関係を変える事は難しい。
- CONTEXTの変更＝変換は大抵影響が大きすぎて一回のリファクタリング（時にはプロジェクト）では終わらない。
- という訳で、次からEvansが変換のガイドラインを提供してくれます。
SEPARATE WAY -> SHARED KERNEL (p389） †
最終目標がCONTINUOUS INTEGRATION による完全な１つのコンテキストへの併合だとしても、まずはSHARED KERNEL から始めなさい
| ステップ１ | 初期の状況を評価しろ
２つのコンテキストが個々の内部で、ちゃんとまとまっているか確かめなさい。 |
| ステップ２ | プロセスを決めなさい。
どのようにコードを共有されるべきか？モジュールのネーミングは？等、共有コードが作成される前に決めねばならない。
少なくともテストを含め、SHARED KERNELコードの週に一度の統合については決めなさい。 |
| ステップ３ | コンテキスト間で重複している（しかし、コアドメインではない）小さなサブドメインから始めなさい
最初の併合はプロセスを確立する事である。（だから、単純で影響の少ない箇所から始めた方が良い。）
既に統合され、変換されているものを試しなさい。 |
同じようなサブドメインを扱う場面に入ったら、次の３つのアプローチがある。つまり
- ひとつのモデルを残し、もう一方をリファクタリングで適合させる。
- サブドメインの中の更に一つの機能（処理）に絞って併合する。
（恐らく両コンテキストにとって最善な結果となる）
- 新しいモデルを見つける。
（恐らく、元のモデルより深遠なモデルになるだろう）
| ステップ４ | 2-4人の開発者からなるグループを形成し、サブドメインに対して共有モデルが機能する様に両チームから結論を得なさい。
この作業には、同音異義語の特定や変換されていない用語のマッピングを含む。 |
| ステップ５ | どちらかのチームの開発者にモデルの実装（又は、共有されるべき既存コードのadapting）を行わせなさい。
もし、開発者らがモデルに関して困難に直面したら、再びチームを召集し、ステップ3からやり直しなさい。 |
| ステップ６ | 個々のチームに新しいSHARED KERNELへの統合を行わせなさい。 |
| ステップ７ | 不必要となったTranslationを除きなさい |
この段階までくると、とても小さなSHARED KERNELがあるはずです。
後続のイテレーションではステップ３〜ステップ７を繰り返しなさい。
プロセスが固まり、チームが自信をようになるにつれて、より複雑で、CORE DOMAINに近いSubdomainを複数、同時に扱えるようになるでしょう。
NOTE：
２つのモデルが異なる専門的な領域向け場面に遭遇するかもしれない。そんな時は、SHARED KERNELへの併合は延期しなさい。
SHARED KERNELの利点はSEPARETE WAYSの利点が修正されている間、CONTINUOUS INTEGRATIONの利点を保持できる事である。
SHARED KERNEL -> CONTINUOUS INTEGRATION（p391） †
SHARED KERNELが拡大していった時、BOUND CONTEXTSの完全な統合の誘惑にかられるかもしれない。
それは、チーム構成と、使用していた言葉を完全に変えることになる。
そんな時は、人々とチームを準備させる事から始めなさい。
| ステップ１ | CONTINUOUS INTEGRATIONの為の全てのプロセス（Shared Codeの所有権や統合の頻度など）が
個々のチームに認識されている事を確認しなさい |
| ステップ２ | チーム間のメンバーを循環させなさい。
両モデルを理解する人間を作る事にるながります。 |
| ステップ３ | 個々のモデルの純度を高めなさい（CHAPTER15参照）
|
ここまでの段階で、CORE DomainをShared Kernelに統合する事に対して十分な自信があるべきである。
| ステップ４ | 一度、CoreDomain?への統合を始めたら、出来る限りの範囲で、素早く行いなさい。
この作業は最もオーバヘッドが高いフェーズであり、エラーを起こしやいからである。 |
| ステップ５ | SHARED KERNELが成熟するにつれて、統合頻度を日時に変えていき、最終的にCONTINUOUS INTEGRATIONへの統合なさい。 |
| ステップ６ | SHARED KERNELが以前のBOUND CONTEXTSを包括するにつれて、２つのチームが、１つの大きなチームか、
以前より小さなメンバーの入れ替えが頻繁に行えるような２つチームになっているだろう。 |
レガシーシステムの移行 （p393） †
- 毎日使われている古いシステムは、ANTICORPORATION LAYERを通してレガシーシステムと連携するより一部のモダンなシステムによって機能追加されている。
- 最初のステップはレガシー用のテスト計画の決定である。
| ステップ１ | 1回のIteratrionで移行が行えるレガシーの機能を特定しなさい。
一回のイテレーションで終わらなくても、小さい機能で、短いイテレーションで行える事を考えなさい。 |
| ステップ２ | ANTICORPORATION LAYERに要求される追加要件を特定しなさい'' |
| ステップ３ | 実装 |
| ステップ４ | 導入
色々なパターンがあるが、普通はより大きな組織的なリリースを考慮する必要がある。
ユーザーは新しいソフトウェアの訓練を受けるべきである。 |
| ステップ５ | ANTICORPORATION LAYERに不要な部分の特定と除去 |
| ステップ６ | レガシーシステムから不要なモデルの除去を考える。
レガシーシステムの設計が良いほど、移行は簡単である。
設計が悪いと、分解も大変である。
全てを切り替えが終わるまで、不要な部分を無視する事は可能かもしれない。 |
この作業を繰り返す事で、レガシーシステムは次第に業務から切り離されていくはずである。
一方で、ANTICORPORATION LAYERは小さくなっていく。
OPEN HOST SERVICE -> PUBLISHED LANGUAGE †
その場しのぎ通信プロトコルで、他システムと連携していると
- アクセスが増すに連れてメンテナンスは大変になる。
- 連携の仕様を理解するのは困難になる。
そんな時は、PUBLISHED LANGUAGEを用い、正式な手順を経てシステム間の関係を構築する必要があるでしょう。
| ステップ１ | 業界標準として使われている言語が存在するならば、それを評価し、可能な限り使いなさい |
| ステップ２ | ステップ１が駄目なら、ホスト（15章参照）のように機能するシステムのCORE Domainに磨きをかけなさい。 |
| ステップ３ | XMLのような交換可能かつ標準的なParadigmを使う時は、可能な限り、交換可能な言語の土台として、CORE DOMAINを使いなさい。 |
| ステップ４ | 新しい言語を公開しなさい。 |
| ステップ５ | もし、新システムの構造が含まれているならば、一緒に公開しなさい |
| ステップ６ | 連携する個々のシステムの為に、translation layerを構築しなさい。 |
| ステップ７ | 切り替えなさい |
- PUBLISHED LANGUAGE は安定していなければなりません
- 過酷なリファクタリングを続けていく為に、交換言語とホストのモデルを同一視してはいけません
- しかし、両者を近づける事は翻訳のオーバヘッドを減らします。
（あなたのホストをCONFORMISTにする事を選択するかもしれません。）
- 一度、BOUND CONTEXT と CONTEXT MAP が明確に定義され、尊重されるようになれば、論理的な一貫性は守られねばならない。
- そうすれば、関連するコミュニケーション問題は対処できるように明らかにされているだろう。
しかし・・・
- 時々CONTEXTは一貫性よりも問題を解決するために誤用される場合がある（それが意図的か否かに関わらず）
- チームは理解するには複雑で大きすぎるCONTEXTを見つけるかもしれない。
- CONTEXTをより管理しやすいサイズに落とし込む事になった場合は、汎用なContextを作成するチャンスを逃がす事になるでしょう。
ということで・・・
- 巨大なモデルを汎用名なCONTEXTとして確立させる為の決断を精査する価値があります。
- もし、寛大なCONTEXTとして統合する事が組織的にも政治的にも難しいのであれば、または、真に分断しているならば、マップを再描画し、管理できるBoundariesを定義しなさい。
- けれども、巨大な BOUNDED CONTEXT が説得力のある統合を要求している一方で、モデルの複雑さの分解を望んでいるならば、CONTEXTを分解する事は最善策ではないかもしれない。
担当者のつぶやき †
- p389 Duplicationって何？Contextを再定義するって事？
- p391 2段落目、noteの箇所「you may encounter cases where ・・・が上手く訳せていません」。専門性の高いモデル同士のSHared Kernelへの併合は、Deep Modelとなるまではやめておきなさい」っていう事？
- p392-step2 「チームメンバを循環させる事を始めなさい」なんてプロジェクト内の政治を無視した理想だと思う。
- p395 ステップ７の直ぐ後、「At this point, additional・・・」以下が訳せません。
「この段階において、追加的な協力者が最小の分解に突入する事が可能であるべきだ」うーん、意味不明・・・
一体、何をdisruptionするんでしょう？「過去のシステム統合によって難しくなった仕様」を、分解するっていう事なんでしょうか？additonalって？
- p395 下から4行目の「to lost oppotunities」って何の「oppotunities」でしょう？
みんなの突っ込み †
