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

Slide 1

Slide 1 text

　 1 コンテキストマップの継続的な活用に向けて 2024年11月7日株式会社 TOKIUM 開発部　イネーブリング東　優太

Slide 2

Slide 2 text

自己紹介プロダクト本部開発部イネーブリング東優太 Yuta Higashi 経歴大手ネット広告会社のエンジニアとして初期のキャリアを経験後、2020年に沖縄移住とともにTOKIUMに参加 2023年にイネーブリングチームに異動し、全体の生産性向上のために尽くす興味領域 Scala / Ruby / DDD / Scrum / SAFe

Slide 3

Slide 3 text

TOKIUMの志未来へつながる時を生む 3 経理の領域でDXを実現する複数のBtoB/SaaSを開発 📊売上推移会社紹介 2年で 4.1倍

Slide 4

Slide 4 text

「コンテキストマップ、作ってますか？」

Slide 5

Slide 5 text

5 コンテキストマップコンテキストマップ DDDの戦略的設計手法の一つで、境界付けられたコンテキストとコンテキスト間の関係性を明らかにすることで、全体の地勢を理解できるようにするものドメイン関係性コンテキストコンテキストドメイン

Slide 6

Slide 6 text

TOKIUMは去年作りました (一番粗い粒度でこんな感じ) 経費精算請求支払経理業務業務代行領収書入力請求書入力書類管理書類入力従業員管理代理受領共通業務ワークフロー

Slide 7

Slide 7 text

7 コンテキストマップの効果「経理業務周りがモノリスだから、分割してリスク分散したいね」「分割したらどんなドメインになる？支払とか？」「今後の新サービスって、どんなコンテキストとして配置されるべきかな」「組織管理や認証は、早めに分離して今後の資産にしたい」システム・プロダクト・ビジネスについて、今の課題は何なのか、どうあるべきか、今後どうなるかを話すことができた

Slide 8

Slide 8 text

「コンテキストマップ、現場は使ってますか？」

Slide 9

Slide 9 text

具体的には... システムやコードと一致していますか？

Slide 10

Slide 10 text

app/ ┗ models/ ┗ groups/ ┗ expenses/ ┗ user.rb ┗ attachment.rb 古いコードはモジュール構造がなかったりモジュールがドメインと一致しなかったり

Slide 11

Slide 11 text

周知不足やミスで意図しないモジュールができたり (メンバー増えると起きがち) 「税金関連の操作なので、taxってモジュール切りました」「既存コードに倣って、直下にクラスを配置しました」

Slide 12

Slide 12 text

あるべき姿が理解されず、あるいは単に強制力がなく放置されたり「結局このクラスってどこに置くのがいいんです？」「今はそんな時間ないので、配置直すのは見送りましょうか」

Slide 13

Slide 13 text

13 コンテキストマップの現実コンテキストマップで抽象化することによって、上位組織にとっては概念レベルでは議論がしやすくなった作って満足せず、現場で意味のあるものにするためには障害があり、継続的な運用に向けた仕組みが必要形骸化しないための努力をしなければならない TOKIUMはモノリスなシステムで複数プロダクト・チームが活動しており、統制をとることが容易ではなかった

Slide 14

Slide 14 text

一般的な解決例

Slide 15

Slide 15 text

15 一般的な解決例マルチプロジェクトビルドコードを複数のプロジェクトやライブラリに分割し、既存コードを移したり、新規コードが配置されるようにする Rubyであればドメインやレイヤー単位にgemを切り分け、依存を整理 gemへの分割を意識して管理すればよさそう (似た選択肢でShopify/packwerkなど) 経費精算インボイス組織管理国税書類

Slide 16

Slide 16 text

16 一般的な解決例マルチプロジェクトビルド思ったよりしんどかった 1. コードの配置変更と、それに伴う参照の書き換え 2. 依存の制限と、それに伴う依存関係の書き換え Rubyは動的型付けなこともあり、エディタの支援が受けづらいやりたい方向性に動かすには、あまりにも体力を要求する作業だったまた、放置されることに対する解決策を見いだせなかった

Slide 17

Slide 17 text

少しずつでいいから何とかしたいいい方法はないだろうか？

Slide 18

Slide 18 text

アーキテクトとしての教科書に出会う

Slide 19

Slide 19 text

19 「ソフトウェアアーキテクチャの基礎」アーキテクチャ適応度関数あるアーキテクチャ特性またはアーキテクチャ特性の組み合わせについて、客観的な整合性評価を行うための何らかの仕組み。 … 適応度関数は統制のための重たい仕組みというよりも、アーキテクトが重要なアーキテクチャの指針を示して、それを自動的に検証する仕組みを提供するものだ「指針を示すこと」と「自動的に検証する」仕組みが必要なことは理解できていたが、検証するコードを自作する例がいくつか載っていた「無ければ作ればいい」　エンジニアとしての原点に気づく

Slide 20

Slide 20 text

20 「ソフトウェアアーキテクチャの基礎」アーキテクチャ適応度関数 gemへの分割ほど厳密に行わず、やりたかったことを少し減らす 1. コードの配置変更と、それに伴う参照の書き換え 2. 依存の制限と、それに伴う依存関係の書き換えコードの配置さえ差分検出すれば、参照のミスはテストで落ちてくれるはず既存で良さげなツールはやっぱり見つからなかった「簡単でいいから作ってみよう」

Slide 21

Slide 21 text

TOKIUM/arch (npm: @tokiumjp/arch)

Slide 22

Slide 22 text

22 TOKIUM/arch 仕組み指定の形式でyamlを書いて、コマンドを実行 yamlに記載した構造と差分があれば、それを表示してエラーになる例: controllers/users だけを許可し、controllers/postsを配置した場合

Slide 23

Slide 23 text

23 TOKIUM/arch 運用コンテキストマップを別yamlに定義し、各ディレクトリにincludeするモジュール構造とコンテキストマップが一致しない状態を解消させ、「各ディレクトリ配下はコンテキストマップに沿うべし」という指針として示せるようになった

Slide 24

Slide 24 text

24 TOKIUM/arch 運用コンテキストマップのymlファイルにCODEOWNERSを設定することで、意図しないモジュールが切られてしまう前に検知できるようになったコンテキストマップは議論の対象として扱われるようになってきた (各チームの担当モジュール配下は各チームに任せ、全体だけを確認する) コンテキストではないディレクトリが切られてもレビューで検知できる

Slide 25

Slide 25 text

25 TOKIUM/arch 運用 PRが出たときにgithub actionsでgitの差分を流してやることで、そのPRで追加・修正されたファイルだけ対象に検出放置されることなく、小さなスコープでコードの配置変更を促せるように

Slide 26

Slide 26 text

26 TOKIUM/arch 運用ちょっとずつ良くなっていることも、カバレッジ測定でわかるようになった

Slide 27

Slide 27 text

少しずつでいいから何とかしたい少しずつだけど何とかなってきた苦労はしたけれど、

Slide 28

Slide 28 text

「コンテキストマップ、現場は使ってますか？」

Slide 29

Slide 29 text

「TOKIUMは、現場も使ってます」

Slide 30

Slide 30 text

TOKIUMに興味を持ってくれた方へ 30 カジュアルなMeetupイベント「寿司とき」を毎月複数回開催中！ 12/07(土) Developers CAREER Boost 2024 登壇します！

Slide 31

Slide 31 text

株式会社TOKIUM 東京都中央区銀座6丁目18-2 野村不動産銀座ビル12階 31 URL : https://www.keihi.com/company