Choosing Your Model Context Strategy(P.381) †
要約 †
いったん現状をもとにコンテキストの地図ができたら、今度は現状を変えたくなるだろう。コンテキストの境界やコンテキスト同士の関連をどのようにするか選ぶ際には、いくつかガイドラインがある。
Team Decision or Higher †
境界の場所や、他のコンテキストとどのような種類の関係を持つのかについて決定は、チームが集まって行わなくてはならない（か、少なくともチーム全体に伝えられなくてはならない）。
コンテキストをどの程度拡張/分割するかは、コストと利益のトレードオフに基づいて決定されなければならない。これは、直接的かつ深い統合の価値と、チーム間の独立した行動の価値とのトレードオフになる。
常に望むような統合戦略を取ることができるわけではないが、少なくとも統合戦略を評価し、そのおかげで被る被害について話し合って、痛みを和らげることはできる。
とにかく、現状をあらわすコンテキストの地図から出発し、どのように変更するか選ぶ際には実利的になることだ。
Putting Ourselves in Context[訳してみたけどよくわからなかったよ] †
ソフトウェア開発プロジェクトの内部にいると、自分のチームが設計している部分に特に大きな興味を持ち、相互作用することになる他のシステム部分への興味は二の次になる。
設計中のシステム部分はたいてい、主要な開発者が従事する1〜2つのBOUNDED CONTEXTに含まれている。もしかしたら、それをサポートするような1〜2つのCONTEXTも含まれているかもしれない。
我々は実際には主要なBOUNDED CONTEXTの一部におり、この事実はコンテキストの地図に反映されていなければならない。
Transforming Boundaries †
BOUNDED CONTEXTの境界を描く方法は多種多様であるが、以下のようなForceのバランスを取るのが重要になる。
- より大きなBOUNDED CONTEXTが望ましくなる要素
- 統合したモデルを使えば、ユーザータスク間のつながりがスムーズになる場合
- 2つのモデルとその間のマッピングより、1つのモデルの方が理解しやすい場合
- 2つのモデル間のTranslationが難しい場合
- 共有言語がチーム間のコミュニケーションを促進する場合
- より小さなBOUNDED CONTEXTが望ましくなる要素
- チーム間のコミュニケーションオーバーヘッドが減る場合
- 小さなチームやコードベースで、CONTINUOUS INTEGRATIONが容易になる場合
- 大きなコンテキストによって、より多用途・万能のモデルが必要になり、スキルが不足する場合
- 複数のモデルを持つことによって、ユビキタス言語の特別な方言に従った、特別なニーズや特定のユーザーグループのみが用いる用語をサポートできる場合。
機能を異なるコンテキスト間で深く統合するのは現実的でない。統合は、あるモデルが他のモデルによって厳密に記述できるような場合に限られるし、このレベルでの統合は高くつくかもしれない。
これ（どれ？深い統合？）は、2システム間のインタフェースが小さい場合にのみ意味がある。
# これ以降は、これまでの原則に従いつつ、ステップバイステプでCONTEXTを決めていく、という風に読むといいです。
Acceptiong That Which We Cannot Change: Delineating the External Systems †
最初は簡単なところからはじめるのがいい。サブシステムの中には、明らかに開発対象システムのどのBOUNDED CONTEXTにも含まれないものがある。
- 例
- すぐに置き換えられないような既存システム
- 必要なサービスを提供してくれるような外部システム
こうしたものを識別し、自分の設計から分離することができる。
これらは独自のBOUNDED CONTEXTを持っていると仮定するのはたやすいが、慎重になる必要がある。というのは…
BOUNDED CONTEXTというのは、ある境界内部のモデルを統合するという意図によって定義される。既存システムをコントロールでき、意図を宣言できたり、CONTINUOUS INTEGRATIONを非公式な形で実施できたりするかもしれないが、これを当然と考えてはならない。きちんと確認し、もし開発がきちんと統合されていないようであれば注意すべきだ。そのようなシステムの内部で意味論的な矛盾が見つかることも多い。
Relationships with the External Systems †
採用できる3つのパターンがある。
- SEPARATE WAYS
- CONFORMIST
- ANTICORRUPTION LAYER
統合の必要がないのに統合することはない。SEPARATE WAYSで十分なのであれば、プロジェクトに余分な重荷を背負わせる必要はない。
CONFORMISTを選ぶと創造性や選択肢が限定されるので愉快なことではなく、重要な新システムを構築する際に既存システムや外部システムに従うのが現実的、というのはあまりありそうにもない。
しかし、今後も主要であり続けるような大きなシステムの周辺部分を拡張する場合には、既存のモデルに従うことが適切になるかもしれない。
- Excelなどを用いた軽量な意思決定サポートツール
上記のような状況で、開発対象と既存システムとのインタフェースが大きくなるような場合、CONTEXT間のTranslationの開発がアプリケーション自体の開発よりも大変になるような事態は簡単に起きうる。
既存システムのモデルに従ってさえいればモデルを改良することもできるし、CONFORMISTに徹して拡張部分の開発に専念することもできる。
開発対象が既存システムに対する拡張の範囲を超えそうであり、開発対象の外部に対するインタフェースが小さいか、他のシステムのデザインがひどいような場合には、独自のBOUNDED CONTEXTを持ち、TranslatorやANTICORRUPTION LAYERを作るときだ。
The System Under Design †
あるプロジェクトチームが実際に構築しているソフトウェアは、「設計対象のシステム(system under design)」である。
その内部にBOUNDED CONTEXTを定義し、統合のためにCONTINUOUS INTEGRATIONを適用することもできる。しかし...どれくらいの数のCONTEXTを持つべきなのか？それらはお互いどのような関係を持つべきなのか？外部システムと共存しなければならない場合と比べると、様々な選択肢がある。
システム全体で1つのCONTEXTを持つようにすることもできる。これは、チームメンバ数が10人を下回っており、高度に関連した機能を開発しているような場合に適切だろう。
チームが大きくなるにつれ、CONTINUOUS INTEGRATIONが困難になってくるかもしれない。SHARED KERNELを使い、機能を比較的独立した部分集合に分割し、それぞれのメンバ数が10人に満たないようなBOUNDED CONTEXTを作ることになるかもしれない。CONTEXT間の関係がすべて1方向なら、CUSTOMER/SUPPLIER DEVELOPMENT TEAMSを採用するかもしれない。
2つのグループのマインドセットがまったく異なり、モデリングがうまくいってない状況に気づくかもしれない。それは、全く異なるモデルが必要なせいかもしれないし、背景知識の違いによるものかもしれないし、管理構造の結果なのかもしれない。この状況を受け入れられない場合、SEPARATE WAYSを取ることになるかもしれない。
統合が必要な箇所では、Transaltionレイヤが設定され、CONTINUOUS INTEGRATIONによって2つのチームが保守することになるかもしれない。これは、ANTICORRUPTION LAYERを用いた外部システムによる統合とは対照的である。ANTICORRUPTION LAYERを使う場合、典型的には一方が他方のシステムにあわせる必要があり、また、他方のシステムによるサポートはほとんど得られない。
一般的に、BOUNDED CONTEXTごとに1つのチームを割り当てるのが良いようだ。1つのチームは複数のBOUNDED CONTEXTを維持できるかもしれないが、複数のチームが同じBOUNDED CONTEXTでうまくやるのは難しい。
Catering to Special Needs with Distinct Models(はっきりと異なるモデルでの特別なニーズにこたえる) †
同じ業務における別グループがそれぞれ独自の専門用語(terminology)を持つことが多い。ローカルな専門語(jargons)はとても精密で彼らのニーズに合うように仕立てられている。これらを変更するには多大なトレーニングと言葉の差異分析が必要になる。かつ新しい専門用語はそれまで活用してきたものよりもうまく役に立たないかもしれない。
個別のBOUNDED CONTEXTSでのこれらの特別なニーズに応えるとすれば、翻訳層(translation layer)のCONTINUOUS INTEGRATIONを省いて、モデルをSEPARATE WAYSへと進めることだ。これらの周りではUBIQUTOUS LANGUAGEの方言化が進んでいく。方言の重なりが多いのであれば、SHARED KERNELを用いることで翻訳コスト(translation cost)を最小化しながら必要な専門化が可能になる。
統合が必要でない、もしくは比較的限られているならば、慣れ親しんだ専門用語の使用を続けられるし、モデルの腐敗(corruption)を避けることもできる。その場合も次のコストとリスクが存在する。
- 共有された言語の欠如によるコミュニケーションの減退
- 統合における大きなオーバヘッド
- 同じ業務領域に対する別個のモデルにおける二重の労力
しかしもっとも大きなリスクは気まぐれで視野の狭いモデルへの変更と正当化の議論である。最も重要なのは「このグループの特定の専門語はどれほど価値があるのか」ということである。価値のない合理的な専門用語の出現に注意しながら、翻訳のリスクに備えるとともにチームの独立したアクションに重きを置かなければならない。
互いに異なった言葉を統一し、それぞれのグループを満足させるような深いモデル(deep model)が現れることがあるかもしれない。仮にそうだとしても難点(catch)は知識が噛み砕かれた開発の後半にそれが現れることである。深いモデルに基づいて計画だてることはできない; あなたはただ機会を待つことしかできないし、戦略を変えて、リファクタリングを行うしかない。
統合の要件が大きなところでは、翻訳のコストのことがどこかに行ってしまうことを心にとめておきなさい。SHARED KERNELにまで至る、複雑な翻訳を必要とするある一つオブジェクトをピンポイントに修正するチーム間の調整の方が、完全な統一化を追い求めるよりもまだ翻訳が容易である。
Deployment †
複雑なシステムのパッケージングとデプロイを調整することは見かけよりもいつも難しいが、退屈なタスクの一つである。BOUDED CONTEXT戦略の選択はデプロイに影響がある。たとえばCUSTOMER/SUPPLIER TEAMSが新しいバージョンをデプロイするとき、同時にテストしたバージョンをリリースするために互いに調整しなければならない。コードとデータ両方のマイグレーションはこれらの組み合わせが作用しなければならない。分散システムでは単独の処理(a single process?)の中でCONTEXTS間の翻訳層を共同で保つことが役に立つ。それにより複数のバージョンが同時に存在することがなくなる。
データマイグレーションに時間がかかるか、分散したシステムが即座に更新されえない場合、単独のBOUNDED CONTEXTのコンポーネントのデプロイでさえ挑戦的な取り組みになりうり、コードとデータの二つのバージョンが共存する結果になってしまうかもしれない。
技術的考慮の多くが開発の環境と技術に依存するようになる。しかしBOUNDED CONTEXTの関係はホットスポットの方向を指し示してくれる。翻訳のインターフェースにマークがつけられる。
デプロイ計画の実行可能性(feasibility)がCONTEXTSの境界を引くのにフィードバックされるべきだ。二つのCONTEXTSが翻訳層でつながっているとき、新しい翻訳層が他方のCONTEXTに対して同じインターフェースを提供する場合のみ、片方のCONTEXTは更新することができる。SHARED KERNELは開発だけでなく、デプロイにも調整により大きな負担がかかる。SEPARATE WAYでは物事がよりシンプルにすることができる。
Trade-off †
ここまでのガイドラインを要約すると、モデルの統一/統合化には戦略の幅がある。一般論として、調整とコミュニケーションの労力とシームレスな機能の統合による利益がトレードオフの関係になる。より独立した行動と、よりスムーズなコミュニケーションとが交換される。より野心的な統合をするには関連するサブシステムの設計へのコントロールが必要である。
When Your Project Is Already Under Way (すでに進行中のプロジェクトの場合) †
よくありそうなこととして、あなたはプロジェクトに参加していないが、すでに進行中のプロジェクトを改善する調査をしているとしよう。このケースにおいて最初のステップは現状に沿ってBOUNDED CONTEXTを定義することである。このことはきわめて重大ななことである。有効であるためには、CONTEXT MAPは、描かれただけのガイドラインに沿って決めた理想的な組織ではなく、チームの真実を写し出していなければならない。
ひとたび現時点の本当の姿のBOUNDED CONTEXTSの輪郭とリレーションを描いたのなら、次のステップは現在の組織におけるチームの慣習(practice)を厳しく引き締めることである。CONTEXTSにおいてあなたのCONTINUOUS INTEGRATIONを改善しなさい。道に迷った翻訳コード(translation code)をあなたのANTICORRUPTION LAYERSにリファクタリングしなさい。今あるBOUNDED CONTEXTSに名前をつけなさい。そしてそれらがプロジェクトのUBIQUTOUS LANGUAGEのなかにいることを確認しなさい。
今ここで、あなたは境界(boundaries)とそのリレーションの変更を考える準備ができた。これらの変更は私がこれまでに新規プロジェクトについて述べてきたのと同じ原則から自然に派生できる。けれども変更は小さく噛み砕き、小さな労力でもっとも価値のある実践的な選択をしなければならない。
次節では実際にいったん決めたあなたのCONTEXT境界を実際に変更する取り組みについて議論する。
担当者のつぶやき †
全訳乙...
とりあえず、半分くらい訳しときました。今岡さんあとよろしくお願いします！…でいいのかな？
→渡邉さん、ありがとうございました。残りも訳しました。こっちも全訳です...
感想としてはこの章のパターンが充分頭に入っていない分、あまり理解できてないかもしれません。あと大規模プロジェクトの経験があればとイメージしやすいのかなと思いました。そうしたら、どうやってパターンを使っていくのか分かりやすくなりそうです。
みんなの突っ込み †
