Table of contents
Open Table of contents
前書き
10 年以上エンジニアとして働いてまして、仕事が安定した去年からずっとソフトウェアエンジニアニングの知識と経験だけだといつまでも生計を立てられなくて、かつエンジニアの道も限界を迎えていると実感しました。
年齢もそうですし外部環境も激変している環境の中で team topologies を読み始めました。素晴らしい本だと思って色々組織作りの勉強もできました。意外かつ嬉しいことに、今年に入ってから早々に身につけたものを仕事に適用できたのです、すこい達成感を感じながら次のステップに邁進していきます！
経緯
我々開発している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 というやり方を試しました。
- 先に開発者をクーポン全機能の担当という役割から解放します。クーポン機能が複数のドメインを含んでいるから、実際にコーディングすると関連のドメインを混ぜて実装しがちです。
- 次は単一クーポンドメイン担当の責任を与えます。そのドメインがやるべきことあるいは外に提供すべきことを考えさせて、インタフェースを出させます。
- 後は使うドメイン例えば注文側の担当者になってもらう。呼び出し元に使いやすいクーポンメソッドを考えさせて、シグニチャーを書かせます。こちらのシグニチャーは大体前ステップのインタフェースと違います。同じだったら逆に密結合の可能性は高いです。
- 最後は単一ドメインから抜け出して全体的に二つのドメインを纏めます。実装側と呼び出し元側の想定は大体違ってそのまま纏めて結合するのはほぼできないんです。よって全機能の担当者の視点に戻って二つドメイン間の食い違いを解決する必要があります。場合によって再び単一ドメイン担当者の視点になる可能性はあります。
一人の開発者に複数ドメイン担当者のロールをプレーさせることによってドメイン跨ぎの密結合を解けました！
後ほど振り返ってみたらこのロールプレーのやり方はまさに Inverse Conway Maneuver です。
決まったアーキテクチャを実現するためにチームを変えるのです： DDD に決められたドメインサービスを疎結合させるために担当者を違うポジションに立たせてそれぞれの角度でドメインを考えさせて結論を出させます。物理的には確かに一人の開発者ですが論理的には複数チームとなります。
それぞれの”チーム”は一次結論を出したらお互いに話し合って最善のインタフェースを作ります。実際にはチーム跨ぎの口頭のコミュニケーションより担当者が考えて違うロール間の食い違いを解決したのです。物理的なチームとはやり方は少し違いますが目的は同じだと思います。図で纏めてみると：
TDD
実はロールプレーしていた時切り替わりのやり方は TDD と結構似ているのを気づきました。TDD 簡単に纏めると: 赤(test 書く) -> 緑(code 書く) -> 赤(test 書く) -> 緑(code 書く) -> … 図で言うと：
同じエンジニアが常に tester ロールと coder ロール間に切り替えてモジュールレベルで違う成果物のテストコードとビジネスロジックコードを作っています。
上のロールプレイも似ています。同じエンジニアが常にドメイン A 担当者ロールとドメイン B 担当者ロール間に切り替えてドメインレベルで違う成果物のサービス A とサービス B を作っています。この理由で最初は両者の間に何か強い関係があると思ってましたが深掘りするとそうではない結論に至りました。
Conway’s Law はチームの疎結合できたらサービスも疎結合できると言っています。ロールプレイによってチームの疎結合はできて関わっているドメインの疎結合もできました。だけどテストコードとビジネスロジックコードは疎結合より高凝集です(少なくともテストコードは単独では存在できない)。tester ロールと coder ロール間に切り替わったとしても同じコンテキストあるいはモジュール内で両者の間にドメインのように著しい境界線は存在してないはずです。
後書き
先には team topologies という素晴らしい本を言及しまして、更に team topologies が参考した本も素晴らしいです。その中の幾つかがエンジニアの私の視座を高めてキャリアパスにより良い影響を与えてくれました。次回是非紹介させてください！