DDD / CONFORMIST

順応 (p.361〜) †

要約 †

[問題についての説明]

• 上流/下流の関係にある２つのチームが同じソースから効率的に導かれていない時、CUSTOMER/SUMPLE TEAMSは機能しない。
  • 2つのチームが管理階層の中でバラバラだったり、チーム間の関係に無関心な責任者をもつ大企業
  • 企業ごとのチーム間で、顧客のビジネスに重要性を見出していない場合。
• どんな理由があろうとも、本質は下流にある。

問題サマリ

• 開発チームが上流/下流に分けられ、上流チームが下流チームとの関係構築に無関心な場合、下流チームは無力である。
• 利他主義である事が上流開発者が約束を守る為の動機付けになるかもしれないが、悲しい事に約束は実現されない。
• 善意を信じる事は決して実現できない機能に基いて、下流チームが計画を立てる事になる。
• 与えられた情報でやりくりしていくしかない事を学ぶまで、下流のプロジェクトは遅れる。
• 下流に合わせられるインタフェースは、ありそうでない。

Therefore:

• 上流チームのモデルに忠実である事によってBOUNDED CONTEXTS間の複雑さの翻訳を排除しろ。
• 下流設計者の方針に枷を嵌め、恐らく理想のモデルから乖離する事になるだろうが、順応を選択する事は、統合を非常に容易にする。
• 供給者（上流チーム）とUBIQUITOUS LANGUAGEを共有する事さえ可能である。
• 供給者は運転席にいるので、コミュニケーションを取るのは容易である。
• 利他主義は上流チームと情報を共有するのに良いものかもしれない。

解決方法サマリ

• CONFIRMの採用有無は、上流への依存次第。
• 採用時は下流アプリケーションの上流への拡張性に対して制限をかける。
• 上記のトレードオフが出来ないのであれば、後述のANTICORRURTION LAYERを作る事で可能な限り下流アプリケーションを隔離しなさい。

• CONFORMISTは、重複する領域のモデルが一緒という点でSHARED KERNELSに似ている。
• 両パターンの違いは意思決定か開発プロセスである。
• SHARED KERNELSは2チームが強く協力し合あうのに対して、CONFORMISTは協力に興味のないチームが融合する事である。
• BOUNDED CONTEXTS間で一連の融合を行ってきた。
• SHARED KERNELS、CUSTOMER/SUMPLE TEAMSはCONFORMISTの側面である。

担当者のつぶやき †

• 日本語的に意味が通るように、ちょっと意訳してます。
• 上流チームへの恨みを感じる嫌味な文章。でも気持ちは分かる（笑）。
• 『CONFORM』の前に『タバコ休憩』をパターン化した方が・・・
• こういう状況でリーダが、どれだけ先頭に立って体を張れるかで、チームの士気も変ってきますよね。

みんなの突っ込み †

まとめ (議事録) †