TypeScriptでモジュラーモノリスやってみた

Transcript

1. TypeScriptでモジュラーモノリスやっ てみた クラスメソッド株式会社 リテールアプリ共創部 マッハチーム morimorikochan

2. 名前 morimorikochan 所属 クラスメソッド株式会社    リテールアプリ共創部    マッハチーム🚀 趣味 Switchのゲーム X @marooon88 ⾃⼰紹介

3. 主な事業 • AWSなんでも（各クラウドなんでも） • 受託開発、⾃社開発、データ分析関連 • 基本全部直案件 クラウドみたいな先端技術に強いIT企業 • ZennやDevelopersIOを運営してます

   3 クラスメソッドとは？

4. 4 マッハチームとは

5. • 単⼀のデプロイ可能なシステム（モノリス）に、ドメイ ンで分割されたモジュールが複数存在している状態 • モノリスとマイクロサービスの中間 🐿モジュラーモノリスとは？ 出典: Modular Monoliths •

   Simon Brown • GOTO 2018

6. 典型的なレイヤードアーキテクチャはこんな感じ 技術的関⼼によって 分割されてる Controller 層 🐿モジュラーモノリスとは？ Order Controller Service 層

   Order Service Repository 層 Order Repository User Controller User Service User Repository Company Controller Company Service Company Repository 参考: Mark Richards Neal Ford 著 島⽥ 浩⼆ 訳 ソフトウェアアーキテクチャの基礎

7. モジュラーモノリスはこんな感じ ドメインによって分割されてる Order ドメイン 🐿モジュラーモノリスとは？ Order Controller Order Service Order

   Repository User ドメイン User Controller User Service User Repository Company ドメ イン Company Controller Company Service Company Repository 参考: Mark Richards Neal Ford 著 島⽥ 浩⼆ 訳 ソフトウェアアーキテクチャの基礎

8. 🤨なんで新規PJで採⽤した？ 技術的関⼼で分離されたレイヤードアーキテクチャを使っていた らつらみが... src/ handler/ ...いろんなファイル use-case/ ...いろんなファイル repository/ ...いろんなファイル

   domain/ ...いろんなファイル

9. つらみ1. ファイル多すぎ問題 システムで扱うドメインの範囲が 広がっていくと、技術で分割され たディレクトリ配下のファイルが 肥⼤化する • 例えば特定のControllerに関 連するRepositoryをたどりに くい

   ◦ 複数のディレクトリをま たぐので 🤨なんで新規PJで採⽤した？ repository/ company-repository user-repository notification-repository coupon-repository coupon-issue-repository campaign-repository campaign-entry-repository order-repository reservation-repository reservation-cancel-repository これに加えてテストコードも...

10. つらみ2. レビューしにくい プルリクエストのdiffが各ディレクトリに散らばってレビューがしにくい 1つのプルリクエストに含まれるのは特定の技術層のコードではなく特定の ドメインのコード（アジャイル開発だと尚更そう） 🤨なんで新規PJで採⽤した？ Controller 層 Order Controller

    User Controller Company Controller Company ドメ イン Company Controller Company こっちじゃなくて こっち

11. 特定の機能だけ独⾃のディレクトリ構成にしたいが、レイヤーの原則を守る ために悩んでしまう‧無理な構成になる （1つのドメインがどんどん複雑になりやすく、こういった機会が多い案件 つらみ3. ⼀部だけ特例的な構成にしにくい 🤨なんで新規PJで採⽤した？ Service 層 Order Service

    Repository 層 Order Repository User Service User Repository Company Service Company Repository 出典: Mark Richards Neal Ford 著 島⽥ 浩⼆ 訳 ソフトウェアアーキテクチャの基礎 Order Quotation Calculator ここでいい んかな❓

12. 👀なんでモジュラーモノリス • つらみを解決できるから ◦ レビューしやすい点 ◦ モジュール内で特例的な 実装を取りやすい点 • モノリスと違ってDynamoDB

    と相性が良い • もしマイクロサービスにする と、開発チームは1つのみなの でチーム単位とサービス単位 が合わない Order ドメイン Order Controller Order Service Order Repository User ドメイン User Controller User Service User Repository Company ドメ イン Company Controller Company Service Company Repository 出典: Mark Richards Neal Ford 著 島⽥ 浩⼆ 訳 ソフトウェアアーキテク

13. 📦具体的にどんなの？ • 階層構造のモジュラーモノリス ◦ 特定のモジュールが肥⼤化した場合に分割しやすいように ◦ Djangoを参考に ◦ 1つのモジュール内はController→Service→Repositoryで構成 ▪

    +DI(Inversify) • serverless-expressで記述されていて、AWS Lambda上で動作 (Lambdalith) • Nest.jsは使ってない ◦ Lambdaのコールドスタート時に時間がかかる • データベースはDynamoDB ◦ RDBと⽐較すると割とテーブルごとに独⽴している ◦ モジュールを跨いだテーブル同⼠の依存が少なく、モジュラーモノ リスの弱点をカバー

14. order/ // モジュール handler/ api-user.ts // エンドユーザーのルーティング api-admin.ts // 管理者のルーティング

    batch.ts // バッチ実⾏エントリーポイント service/ create-order.ts export-orders.ts order-repository.ts order.ts 📦具体的にどんなの？ こんな感じ→

15. order/ // モジュール handler/ api-user.ts // エンドユーザーのルーティング api-admin.ts // 管理者のルーティング

    batch.ts // バッチ実⾏エントリーポイント service/ create-order.ts export-orders.ts order-repository.ts order.ts order-quotation-calculator/ // ⼦モジュール service/ calculate-quotation.ts quotation.ts 📦具体的にどんなの？ こんな感じ→

16. 💪どうだった？ • 実は運⽤して1ヶ⽉も経ってない • 構築して思ったこと ◦ つらみは解消できそう ◦ 実装時に⼀定の設計スキルが必要になる ▪

    思考停⽌で実装できるものではない。 ▪ モジュールに切り出すか常に⾒極める必要がある ▪ その点では技術ベースのレイヤードアーキテクチャは楽 ◦ モジュール内はある程度散らかっていても保守性への影響は少ない ◦ モジュールの境界をちゃんと決めないとモジュール間の依存関係が 複雑になって保守性が⼤きく下がりそう... ▪ Shopifyのブログでも強く⾔及されている

17. 🤬課題: モジュールの境界をどう定義し制約するか TypeScriptは“export”されると どこからでも呼び出しができる →放置すると他のモジュールか らでも無秩序にexportできる （例: OrderRepositoryから UserServiceを呼び出す） ⾃動で‧できるだけ早く検知し

    たい Order ドメイン Order Controller Order Service Order Repository User ドメイン User Controller User Service User Repository Company ドメ イン Company Controller Company Service Company Repository

18. 🤬課題: モジュールの境界をどう定義し制約するか Linterを使う • eslintを使っていれば no-restricted-pathsが使え ない🥺 • biomeだと useImportRestrictionsが

    使える！ Order ドメイン Order Controller Order Service Order Repository User ドメイン User Controller User Service User Repository Company ドメ イン Company Controller Company Service Company Repository

19. 🤬課題: モジュールの境界をどう定義し制約するか // 親ディレクトリ のファイル はなんでも importできる import { exportedValue

    as e1 } from "./../exportedValue"; // 同じディレクトリのファイルはなんでも importできる import { exportedValue as e2 } from "./exportedValue"; // 子ディレクトリは index.tsだけ import { exportedValue as e3 } from "./fuga"; import { exportedValue as e4 } from "./fuga/exportedValue"; //ERROR

20. • レイヤードアーキテクチャ（技術ベース）のつらみは解消できそ う • 課題もある ◦ 実装時に⼀定の設計スキルが必要になる ◦ モジュールの境界をどう定義し制約するか ▪

    biomeだとuseImportRestrictions が今の所良さそう • 感想 ◦ 何年後かに答え合わせでまた登壇できるといいな 📚結論‧感想

21. Rustについて興味ある⼈いませんか...？ サーバーサイドTypeScriptについて興味ある⼈いませんか...？ 🫠宣伝

22. ありがとうございました 🫠おわり