コンテキストマップの継続的な活用に向けて

Transcript

1. 　 1 コンテキストマップの継続的な活用に向けて 2024年11月7日 株式会社 TOKIUM 開発部　イネーブリング 東　優太
2. 自己紹介 プロダクト本部 開発部 イネーブリング 東 優太 Yuta Higashi 経歴 大手ネット広告会社のエンジニアとして初期のキャリアを 経験後、2020年に沖縄移住とともにTOKIUMに参加 2023年にイネーブリングチームに異動し、全体の生産性向 上のために尽くす 興味領域 Scala / Ruby / DDD / Scrum / SAFe
3. TOKIUMの志 未来へつながる時を生む 3 経理の領域でDXを実現する複数のBtoB/SaaSを開発 📊売上推移 会社紹介 2年で 4.1倍
4. 「コンテキストマップ、作ってますか？」
5. 5 コンテキストマップ コンテキストマップ DDDの戦略的設計手法の一つで、境界付けられたコンテキストと コンテキスト間の関係性を明らかにすることで、 全体の地勢を理解できるようにするもの ドメイン 関係性 コンテ キスト コンテ キスト ドメイン
6. TOKIUMは去年作りました (一番粗い粒度でこんな感じ) 経費精算 請求支払 経理業務 業務代行 領収書入力 請求書入力 書類管理 書類入力 従業員 管理 代理受領 共通業務 ワーク フロー
7. 7 コンテキストマップの効果 「経理業務周りがモノリスだから、分割してリスク分散したいね」 「分割したらどんなドメインになる？支払とか？」 「今後の新サービスって、どんなコンテキストとして配置されるべきかな」 「組織管理や認証は、早めに分離して今後の資産にしたい」 システム・プロダクト・ビジネスについて、 今の課題は何なのか、どうあるべきか、今後どうなるかを話すことができた
8. 「コンテキストマップ、現場は使ってますか？」
9. 具体的には... システムやコードと一致していますか？
10. app/ ┗ models/ ┗ groups/ ┗ expenses/ ┗ user.rb ┗ attachment.rb 古いコードはモジュール構造がなかったり モジュールがドメインと一致しなかったり
11. 周知不足やミスで 意図しないモジュールができたり (メンバー増えると起きがち) 「税金関連の操作なので、taxってモジュール切りました」 「既存コードに倣って、直下にクラスを配置しました」
12. あるべき姿が理解されず、 あるいは単に強制力がなく 放置されたり 「結局このクラスってどこに置くのがいいんです？」 「今はそんな時間ないので、配置直すのは見送りましょうか」
13. 13 コンテキストマップの現実 コンテキストマップで抽象化することによって、上位組織にとっては 概念レベルでは議論がしやすくなった 作って満足せず、現場で意味のあるものにするためには障害があり、 継続的な運用に向けた仕組みが必要 形骸化しないための努力をしなければならない TOKIUMはモノリスなシステムで複数プロダクト・チームが活動しており、 統制をとることが容易ではなかった
14. 一般的な解決例
15. 15 一般的な解決例 マルチプロジェクトビルド コードを複数のプロジェクトやライブラリに分割し、 既存コードを移したり、新規コードが配置されるようにする Rubyであればドメインやレイヤー単位にgemを切り分け、依存を整理 gemへの分割を意識して管理すればよさそう (似た選択肢でShopify/packwerkなど) 経費精算 インボイス 組織管理 国税書類
16. 16 一般的な解決例 マルチプロジェクトビルド 思ったよりしんどかった 1. コードの配置変更と、それに伴う参照の書き換え 2. 依存の制限と、それに伴う依存関係の書き換え Rubyは動的型付けなこともあり、エディタの支援が受けづらい やりたい方向性に動かすには、あまりにも体力を要求する作業だった また、放置されることに対する解決策を見いだせなかった
17. 少しずつでいいから何とかしたい いい方法はないだろうか？
18. アーキテクトとしての教科書に出会う
19. 19 「ソフトウェアアーキテクチャの基礎」 アーキテクチャ適応度関数 あるアーキテクチャ特性またはアーキテクチャ特性の組み合わせについて、 客観的な整合性評価を行うための何らかの仕組み。 … 適応度関数は統制のための重たい仕組みというよりも、アーキテクトが 重要なアーキテクチャの指針を示して、それを自動的に検証する仕組みを 提供するものだ 「指針を示すこと」と「自動的に検証する」仕組みが必要なことは理解でき ていたが、検証するコードを自作する例がいくつか載っていた 「無ければ作ればいい」　エンジニアとしての原点に気づく
20. 20 「ソフトウェアアーキテクチャの基礎」 アーキテクチャ適応度関数 gemへの分割ほど厳密に行わず、やりたかったことを少し減らす 1. コードの配置変更と、それに伴う参照の書き換え 2. 依存の制限と、それに伴う依存関係の書き換え コードの配置さえ差分検出すれば、参照のミスはテストで落ちてくれるはず 既存で良さげなツールはやっぱり見つからなかった 「簡単でいいから作ってみよう」
21. TOKIUM/arch (npm: @tokiumjp/arch)
22. 22 TOKIUM/arch 仕組み 指定の形式でyamlを書いて、コマンドを実行 yamlに記載した構造と差分があれば、それを表示してエラーになる 例: controllers/users だけを許可し、controllers/postsを配置した場合
23. 23 TOKIUM/arch 運用 コンテキストマップを別yamlに定義し、各ディレクトリにincludeする モジュール構造とコンテキストマップが一致しない状態を解消させ、 「各ディレクトリ配下はコンテキストマップに沿うべし」 という指針として示せるようになった
24. 24 TOKIUM/arch 運用 コンテキストマップのymlファイルにCODEOWNERSを設定することで、 意図しないモジュールが切られてしまう前に検知できるようになった コンテキストマップは議論の対象として扱われるようになってきた (各チームの担当モジュール配下は各チームに任せ、全体だけを確認する) コンテキストではない ディレクトリが切られても レビューで検知できる
25. 25 TOKIUM/arch 運用 PRが出たときにgithub actionsでgitの差分を流してやることで、 そのPRで追加・修正されたファイルだけ対象に検出 放置されることなく、小さなスコープでコードの配置変更を促せるように
26. 26 TOKIUM/arch 運用 ちょっとずつ良くなっていることも、カバレッジ測定でわかるようになった
27. 少しずつでいいから何とかしたい 少しずつだけど何とかなってきた 苦労はしたけれど、
28. 「コンテキストマップ、現場は使ってますか？」
29. 「TOKIUMは、現場も使ってます」
30. TOKIUMに興味を持ってくれた方へ 30 カジュアルなMeetupイベント「寿司とき」を 毎月複数回開催中！ 12/07(土) Developers CAREER Boost 2024 登壇します！
31. 株式会社TOKIUM 東京都中央区銀座6丁目18-2 野村不動産銀座ビル12階 31 URL : https://www.keihi.com/company