inverse conway maneuverと自分なりの考え

こんにちは。 Showcase Gig PF2チーム所属のリョです。 入社してから今まではfrontendのことをやってきまして、最近チームの編成によってbackendに復帰しました。復帰早々開発しながらおもしろいことを思いついたのでここでまとめてみました。

経緯

我々開発しているO:der Platformはモバイルオーダーのプロダクトを支えています。最近新しいクーポンの機能を作ってました。

クーポンは注文、会計などと関わっているので既存のドメインに対していろいろ修正する必要があります。会社の事情があるのでクーポンとそれぞれ関連ところの修正は一人のエンジニアに任せまして私はレビュー役として携わっていた。

二人で一緒にやりながら Conway's Law がどういう形で実際の仕事に影響しているかを実験しまして、そして Conway's Law、DDD と TDD について自分なりの発想が湧いてきました。

Conway's Law

Conway's Lawについては特に説明するまではないです。簡単に言えば組織の構造はシステムの構造を決めます。

先ほど説明した通りエンジニア一人で関連のドメインをいじって開発していましたが、結果としては完全に Conway's Law の通りでクーポン、注文、会計などのドメインは密結合になりました。よってコードは可読性が低下してメンテナンスもしにくくなりました。図でまとめてみると。

Inverse Conway Maneuver

品質を上げるために何かしないといけないと思っていろいろ考えてみました。

今までは担当者がクーポン機能を実現するためには商品カート入れ、注文、会計一連の処理を分割不可能だと考えて無意識的に context の境界線を見落としました。それをはっきりさせるために role play というやり方を試しました。

• 先に開発者をクーポン全機能の担当という役割から解放します。クーポン機能が複数のドメインを含んでいるから、実際にコーディングすると関連のドメインを混ぜて実装しがちです。

• 次は単一クーポンドメイン担当の責任を与えます。そのドメインがやるべきことあるいは外に提供すべきことを考えさせて、インタフェースを出させます。

• 後は使うドメイン例えば注文側の担当者になってもらう。呼び出し元に使いやすいクーポンメソッドを考えさせて、シグニチャーを書かせます。こちらのシグニチャーはだいたい前ステップのインタフェースと違います。同じだったら逆に密結合の可能性は高いです。

• 最後は単一ドメインから抜け出して全体的に2つのドメインをまとめます。実装側と呼び出し元側の想定はだいたい違ってそのまままとめて結合するのはほぼできないんです。よって全機能の担当者の視点に戻って2つドメイン間の食い違いを解決する必要があります。場合によって再び単一ドメイン担当者の視点になる可能性はあります。

一人の開発者に複数ドメイン担当者のロールをプレーさせることによってドメイン跨ぎの密結合を解けました！

のちほど振り返ってみたらこのロールプレーのやり方はまさに Inverse Conway Maneuver です。

決まったアーキテクチャを実現するためにチームを変えるのです： DDD に決められたドメインサービスを疎結合させるために担当者を違うポジションに立たせてそれぞれの角度でドメインを考えさせて結論を出させます。物理的にはたしかに一人の開発者ですが論理的には複数チームとなります。

それぞれの"チーム"は一次結論を出したらお互いに話し合って最善のインタフェースを作ります。実際にはチーム跨ぎの口頭のコミュニケーションより担当者が考えて違うロール間の食い違いを解決したのです。物理的なチームとはやり方は少し違いますが目的は同じです。図でまとめてみると：

TDD

実はロールプレーしていた時切り替わりのやり方は TDD と結構似ているのを気付きました。TDD 簡単にまとめると: 赤(test 書く) -> 緑(code 書く) -> 赤(test 書く) -> 緑(code 書く) -> ... 図で言うと：

同じエンジニアが常に tester ロールと coder ロール間に切り替えてモジュールレベルで違う成果物のテストコードとビジネスロジックコードを作っています。

上のロールプレイも似ています。同じエンジニアが常にドメイン A 担当者ロールとドメイン B 担当者ロール間に切り替えてドメインレベルで違う成果物のサービス A とサービス B を作っています。この理由で最初は両者の間に何か強い関係があると思ってましたが深掘りするとそうではない結論に至りました。

Conway's Law はチームの疎結合できたらサービスも疎結合できると言っています。ロールプレイによってチームの疎結合はできて関わっているドメインの疎結合もできました。だけどテストコードとビジネスロジックコードは疎結合より高凝集です(少なくともテストコードは単独では存在できない)。tester ロールと coder ロール間に切り替わったとしても同じコンテキストあるいはモジュール内で両者の間にドメインのように著しい境界線は存在してないはずです。