Tweet
Tweet

Slide 1

Slide 1 text

@PHPerKaigi 2025（3/23） プログラミングをするパンダ（@Panda_Program） モジュラーモノリスでスケーラブルな システムを設計・実装する - BASE のリアーキテクチャのいま 1

Slide 2

Slide 2 text

2 © 2012-2025 BASE, Inc. 自己紹介 ● BASE株式会社 ● 所属：BASE / Product Dev / feature dev1 ● 現在の仕事：シニアエンジニア ○ フロントエンドもバックエンドも書くフルスタックです ○ スクラム開発やチームの開発プロセスの改善が好きです ● 好きなことと活動 ○ 執筆 ○ CodeZine様で「バックエンドエンジニアのためのフロントエンド入門」を現在連載中 ○ Software Design 2022年3月号で TDD 特集の2,3部を執筆しました ○ 登壇 ○ Developers Summit 2025、PHP Conference 2022など ○ twitter: @Panda_Program プログラミングをするパンダ（@Panda_Program）

Slide 3

Slide 3 text

3 © 2012-2025 BASE, Inc. 宣伝 YouTubeでエンジニア向けのラジオを配信してます（@dialog-radio） https://www.youtube.com/@dialog-radio/videos ● ブログや登壇とはまた違った内容です ○ プロダクトエンジニアって何だろう？ ○ プロダクトオーナーとエンジニアの違い とは？ ○ 勉強会のスキルアップ以外の意義とは？ ● 毎週月曜日、朝7時配信 ○ ぜひご視聴 & チャンネル登録お願 いします！

Slide 4

Slide 4 text

4 © 2012-2025 BASE, Inc. はじめに https://speakerdeck.com/nazonohito51/base-rearchitecturing

Slide 5

Slide 5 text

5 © 2012-2025 BASE, Inc. はじめに 本日お伝えしたいこと ● BASEの新規開発はモジュラーモノリス上で行われている ● PHP界隈でのBASEのイメージを少しでも刷新したい ● アーキテクチャの話は設計者であるアーキテクト自身が話すことが多い ○ それを利用する現場のエンジニアが発表すると違った角度になって意義があるのでは？

Slide 6

Slide 6 text

6 © 2012-2025 BASE, Inc. 目次 １ ２ ３ モジュラーモノリスとは BASEのリアーキテクチャの目的 リアーキテクチャの現在地 4 4年前の狙いと今

Slide 7

Slide 7 text

7 © 2012-2025 BASE, Inc. 1. モジュラーモノリスとは

Slide 8

Slide 8 text

8 © 2012-2025 BASE, Inc. モジュラーモノリスとは 大規模なモノリスを マイクロサービスに分割しよう というトレンドがあった

Slide 9

Slide 9 text

9 © 2012-2025 BASE, Inc. モジュラーモノリスとは しかし、マイクロサービスは大変

Slide 10

Slide 10 text

10 © 2012-2025 BASE, Inc. モジュラーモノリスとは Monolith First（2015年） 新しいプロジェクトを開始する際には、マイク ロサービスではなくモノリスから始めるべきで あり、特にシンプルなアプリケーションの場合 はその方が効果的である。 モノリスを先に構築することで、サービス間の 適切な境界を特定し、マイクロサービスへの移 行をスムーズに行うことができる。 → 適切な境界を見つけた後に、少しずつマイ クロサービス化することを提案 早すぎるマイクロサービス化への警鐘 Monolith First（Martin Fowler） https://martinfowler.com/bliki/MonolithFirst.html

Slide 11

Slide 11 text

11 © 2012-2025 BASE, Inc. モジュラーモノリスとは マイクロサービスの前に しっかりモノリスで開発する

Slide 12

Slide 12 text

12 © 2012-2025 BASE, Inc. モジュラーモノリスとは そうは言っても 大規模になったモノリスは大変 マイクロサービスはもっと大変 じゃあ、どうする...？

Slide 13

Slide 13 text

13 © 2012-2025 BASE, Inc. モジュラーモノリスとは 両者の良いところを持った アーキテクチャ

Slide 14

Slide 14 text

14 © 2012-2025 BASE, Inc. モジュラーモノリスとは What Is a Modular Monolith?（Milan Jovanović） https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith

Slide 15

Slide 15 text

15 © 2012-2025 BASE, Inc. モジュラーモノリスとは モジュラーモノリスは、独立したモジュールや コンポーネントにアプリケーションを構造化す るアーキテクチャパターン。 関連機能をグループ化することでシステムの凝 集性を大幅に改善する。 メリット ● 簡単なデプロイ（1つデプロイすればいい） ● 開発速度の向上（←コードの論理的な分割） ● トランザクション管理が容易（MSAと比較） ● 運用の複雑さの低減 ● マイクロサービスへの移行が容易 モジュラーモノリスの定義 What Is a Modular Monolith?（Milan Jovanović） https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith

Slide 16

Slide 16 text

16 © 2012-2025 BASE, Inc. モジュラーモノリスとは Shopifyの事例（2019年） ● モノリスで困っている ○ 異なる機能が同一のコードベースに密結合 ○ 機能間の独立性が低い ● しかし、マイクロサービスは選びたくない ○ 小さなサービスの集合体 ○ サービス間の通信による遅延 ○ トランザクション制御が難しい ● このため、モジュラーモノリスを選択 ○ 単一のアプリケーション内でモジュール性 を高める ○ モノリスとマイクロサービスの利点がある モノリスからモジュラーモノリスへ移行事例 [翻訳] Shopifyにおけるモジュラモノリスへの移行（@tkyowa） https://qiita.com/tkyowa/items/ae9fa550237cb6f48318

Slide 17

Slide 17 text

17 © 2012-2025 BASE, Inc. モジュラーモノリスとは Modular Monoliths • Simon Brown • GOTO 2018 https://www.youtube.com/watch?v=5OjqD-ow8GE

Slide 18

Slide 18 text

18 © 2012-2025 BASE, Inc. モジュラーモノリスとは モノリスを育てながら境界を探して モジュラーモノリスとして分割する

Slide 19

Slide 19 text

19 © 2012-2025 BASE, Inc. 2. BASEのリアーキテクチャの目的

Slide 20

Slide 20 text

20 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 モジュラーモノリスを 採用した背景

Slide 21

Slide 21 text

21 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 BASE大規模リアーキテクチャリング（Satoshi Kawashima） https://speakerdeck.com/nazonohito51/base-rearchitecturing

Slide 22

Slide 22 text

22 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 以下はこのスライドの要約

Slide 23

Slide 23 text

23 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 [背景] 10年近いサービス + コロナでECが脚光 → エンジニア採用強化で組織拡大へ [課題] 1. モノリス上のコードベースの巨大化 2. 古いテクノロジー（古いフレームワーク） 3. トラフィックの急増 4. 組織拡大によるアウトプット量の低下 → 中長期的なアーキテクチャ戦略が必要 当時直面していた課題

Slide 24

Slide 24 text

24 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 BASEの中⻑期的なアーキテクチャ戦略とは、 チームを最小単位とした組織的学習を持続させ、 ビジネス・テクノロジー・組織の変化に対応しながら、 高い生産性を維持して事業競争力を得るための システムの構造を作り、維持することである （パンダの要約）

Slide 25

Slide 25 text

25 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 LeanとDevOpsの科学（通称Accelerate本） 「事業競争力とデリバリパフォーマンスに正 の相関がある。ユーザーのフィードバックを 素早く得られるから」 デリバリを高速化し、PDCAを素早く回して 目的不確実性と方法不確実性（=「何を」 「どのように」作れば良いのかわからない） に対処する この組織的学習をチーム単位で実施する。 チームこそが学習の最小単位である 組織的学習に力を入れる

Slide 26

Slide 26 text

26 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 ビジネス・組織・テクノロジーの変化に対応 ● ビジネス ○ ビジネス環境 ○ プロジェクト組成・解散 ○ etc. ● テクノロジー ○ 適切なモジュール境界 ○ トレンドやバージョンアップ ○ etc. ● 組織 ○ 人の入れ替わり ○ etc. 変化に対応する

Slide 27

Slide 27 text

27 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 高い生産性と事業競争力 「事業競争力とデリバリパフォーマンスに正 の相関がある」 生産性が高い組織は、以下のケイパビリティ を持つ（= 以下のことが出来ている） ● チームによる実験の奨励‧実現 ● チームへのツール選択権限の付与 ● 疎結合のアーキテクチャ ● 負担の軽い変更承認プロセス ● etc. これらを実現するシステム構成にしたい

Slide 28

Slide 28 text

28 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 「アーキテクチャ」は組織の生産性を支え続 けるためのシステム構造。 チームを元にしたPDCAサイクルを組織全体 で回すことで、目的不確実性と方法不確実性 に対処するアーキテクチャを目指す。 そのためにモジュラーモノリスを採用した ● 例えば ○ 1つのチームが1つのモジュールを担当し て、モジュール単位で学習・最適化する ○ 境界線もマイクロサービスより楽に引き 直せる システムの構造 BASE大規模リアーキテクチャリング（Satoshi Kawashima） https://speakerdeck.com/nazonohito51/base-rearchitecturing

Slide 29

Slide 29 text

29 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 俺たちの戦いはこれからだ（終）

Slide 30

Slide 30 text

30 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 前回の発表から 2年半後の今 どうなったの？

Slide 31

Slide 31 text

31 © 2012-2025 BASE, Inc. 3. リアーキテクチャの現在地

Slide 32

Slide 32 text

32 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 A B C 準備 設計 実装（i. 共通基盤, ii. モジュール） D 運用・リアーキテクチャ

Slide 33

Slide 33 text

33 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 A. 準備

Slide 34

Slide 34 text

34 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 Big Picture Event Storming を実施 ● 参加者 ○ エンジニア（Platform チーム） ○ エンジニア（その領域に明るい人たち） ○ プロダクトマネージャー ● 目的 ○ 領域ごとの境界を把握したい ○ 1領域 = 1モジュールとする 1領域1.5時間とか3時間とかかかったらしい 現在15モジュールある（決済、認証など） イベントストーミング（2022年6月）

Slide 35

Slide 35 text

35 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 サービス領域ごとに展開 GitHub Actions で ECS にデプロイ インフラが分かれているため、繁忙期で負荷が 高まった時に決済部分だけスケールアウトする などが可能 インフラの整備

Slide 36

Slide 36 text

36 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 B. 設計

Slide 37

Slide 37 text

37 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 3層構造クリーンアーキテクチャで構成 ● Gateways 層（1層目） ○ Controller や Command など ○ Repository や Logger などの実装 Gateways は実装の詳細である RoutingにCakePHP5を使っているが、 FW依存があるのはこのレイヤーだけ クリーンアーキテクチャベースのモジュラーモノリス（外側） BASE大規模リアーキテクチャリング（Satoshi Kawashima） https://speakerdeck.com/nazonohito51/base-rearchitecturing

Slide 38

Slide 38 text

38 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 この2層がモジュール（BaseIncModule） ● Application（2層目） ○ UseCase（サービス層） ● Domain（3層目） ○ ドメインオブジェクト ■ Entity ■ Value Object ○ インターフェース 現在15モジュール存在している クリーンアーキテクチャベースのモジュラーモノリス（内側） BASE大規模リアーキテクチャリング（Satoshi Kawashima） https://speakerdeck.com/nazonohito51/base-rearchitecturing

Slide 39

Slide 39 text

39 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 ディレクトリ構成（簡略化） services ├── modules（内側） │ └── Someモジュール │ ├── Application │ │ └── CreateFooUseCase │ └── Domain │ ├── Foo │ └── FooRepositoryInterface └── src（外側。Gateways 層） ├── Controller │ └── FooController └── ModuleImplements └── Someモジュール └── Persistent └── FooRepository クリーンアーキテクチャベースのモジュラーモノリス（ディレクトリ構成）

Slide 40

Slide 40 text

40 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 C. 実装 i. モジュールの共通基盤

Slide 41

Slide 41 text

41 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 UnitOfWorkを内包したトランザクションマ ネージャーでDBトランザクションの制御を自 動化→begin~commitの記述は基本的に不要 アプリケーション内で発生する個々の更新 （INSERT、UPDATE、DELETE）を都度実行 するのではなく、一旦UnitOfWorkに登録し、 最後にまとめて実行する。 モジュール間通信でDBを操作しても、同一ト ランザクションとして扱える （トランザクション整合性の破壊防止） トランザクション管理 - UnitOfWork モジュラモノリスにおけるトランザクション設計の考え方（Satoshi Kawashima） https://speakerdeck.com/nazonohito51/transaction-design-on-modular-monolith

Slide 42

Slide 42 text

42 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 DomainEventを起点としたイベント駆動な処 理を書けるようになっている ● DomainEventはEntityのライフサイクル変 化で発生する ● イベントは永続化時に自動でpublishされる ● リスナーは同期・非同期実行を選択できる 開発者がドメインルールの実装に集中すること が狙い ex. メンバーシップを開設する（開設Event） → 開設完了メールを送信する（開設Mail送信EventListener） ドメインイベントとイベントリスナー（同期・非同期）

Slide 43

Slide 43 text

43 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 ● 同期的な連携 - ModuleProxy ○ 他のモジュールから呼べる Public な API ○ メソッドコールで実現する ● 非同期的な連携 - 非同期イベントリスナー 非同期で問題ない場合は、非同期が望ましい ex. 仮に顧客管理、通知が別モジュールであり同期 連携である場合、 メンバーシップの開設ボタンを押す → メールサーバーのエラーでメール送信に失敗する → 開設に失敗する → 開設ができない + 顧客の不満につながる モジュール間連携 What Is a Modular Monolith?（Milan Jovanović） https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith

Slide 44

Slide 44 text

44 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 社内ドキュメントに書いてます ● DI 機構 - Ray.DI ● Open API によるスキーマ定義 ● SQS Worker ● 認証 ● バッチ - ECS Scheduled Taskで実現 ● ロギング ● テスト用モジュール ● 他サービスとのDBスキーマの共有 kawashimaさんいつか話してね その他いっぱい

Slide 45

Slide 45 text

45 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 C. 実装 ii. モジュール

Slide 46

Slide 46 text

46 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 各プロジェクトではドメイン駆動設計によって 開発作業を行っている ● ドメインモデリング、ドメインルールを探す ● ドメインイベントを特定するためにイベント ストーミングを実施するなど ● （いれば）ドメインエキスパートとの会話 必要に応じてイネーブリングチームがドメイン 駆動設計の手ほどきをすることで、各チームが 最終的に自律して開発可能になるように手伝い をしている Domain層の開発 あるチームのイベントストーミングの様子

Slide 47

Slide 47 text

47 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 Domain層のオブジェクトとInterfaceを利用 するサービス層 ● UseCase ○ HttpResponsable 型を返す ● Factory ● メール通知サービス etc. 将来はAIが書くようになるかも？by kawashima Application層の開発

Slide 48

Slide 48 text

48 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 クリーンアーキテクチャの一番外側 インターフェースで定義したクラスを実装する ● 永続化層（CQRSを意識） ○ Repository ○ QueryService ● Web ○ Controller ● Shell ○ Command etc. CakePHP5に対する依存があるのはここだけ Gateway層の開発

Slide 49

Slide 49 text

49 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 テストのしやすさ、デプロイの単純化、チーム間のコミュニケーションはうまくいっている それでも課題はある ● 学習コストの高さ ○ モジュラーモノリス自体の考え方を習得しないといけない ○ モジュールの中を書くときMVCしか慣れてない人には育成・勉強の必要がある ● 機能実装やリアーキテクチャが未完了 ○ モジュールをまたぐ開発、まだモノリス側にしか機能がない etc. ■ どのチームがどのタイミングで実装する？ ● 全体のイベントストーミングは過去に一度開かれただけ ○ なぜこの構成か、各モジュールの役割は何かを理解する機会が少ない ○ 「イベントストーミングは定期的にやったほうがいい」は一般論らしい ■ 人の入れ替わり、理解の深まり、状況の変化 etc.

Slide 50

Slide 50 text

50 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 学べることがたくさんある（現場のエンジニアの感想） ● きっとどこでも通用するエンジニアになれる ○ モジュラーモノリスという中大規模の企業の技術トレンドに乗った開発経験が積める ○ しっかりしたオブジェクト指向の設計力が身につく ■ EntityとValue Objectでドメイン層を構築していく ■ 外部 SDK のバージョンアップも、依存クラスの差し替えで完了した（DIの力） ■ コア機能に改修を加える開発でもコンフリクト懸念が全然ない ● 開発するドメインのことに集中できる ○ 技術的なことを乗り越えたら、やりたいこと・やるべきことに集中できる ○ PdM、デザイナーを巻き込んでイベントストーミングをしているチームもある

Slide 51

Slide 51 text

51 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 超おすすめ書籍 ● OOPの設計力が確実にレベルアップする ● Domain層とApplication層の設計に役立つ ● 社内でも評判が良い（勉強会2回開催済み） ○ 「EntityとValue Objectを理解できた」 ○ 「ドメインイベントの意義が分かった」 ○ 「もっと早く読みたかった」 「軽量DDDはもういらない！ スタイルガイド本で OOPの実装パターンを学ぼう」(1.4万view)で紹介 https://speakerdeck.com/panda_program/no-more-lightweight-ddd オブジェクト設計スタイルガイド

Slide 52

Slide 52 text

52 © 2012-2025 BASE, Inc. 宣伝 読書会をします - 04/11（金） 19:00 ~ ● ROSCAさん主催で『オブジェクト設計スタイル ガイド』の読書会をします #ROSCAFE ● 会場はBASE（六本木一丁目）です https://rosca.connpass.com/event/348360/

Slide 53

Slide 53 text

53 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 D. 運用・リアーキテクチャ

Slide 54

Slide 54 text

54 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 モジュラーモノリスの運用 ● デプロイ ○ GitHub Actions からデプロイ ○ 社内サーベイで CD/CI が高評価 ■ 高速デプロイの実現 ● Slack にエラー通知 ● NewRelicのダッシュボードで監視 ○ （まだないモジュールもある） 運用

Slide 55

Slide 55 text

55 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 ● DryRun ○ 移行前の旧機能と新機能を同時実行し、永続化の 結果を比較するツール ○ 「リアーキテクチャをお手伝いするDryRunというツール を作りました」 ■ https://devblog.thebase.in/entry/2024/06/14/110000 ● イベントによるサービス間連携 ○ 旧環境のモノリスでイベントを発行し、モジュ ラーモノリスでイベントリスナーを動かせる ■ 移行作業がまだでも新システムで処理を書ける ● DBのアクセス制限 ○ モジュールごとにアクセス可能なテーブルを制 限。CIで違反をチェック リアーキテクチャ支援 - プラットフォームチームによる Team Topologies の輪読会用の備忘録 https://zenn.dev/tabio/articles/team-topologies

Slide 56

Slide 56 text

56 © 2012-2025 BASE, Inc. 4. 4年前の狙いと今

Slide 57

Slide 57 text

57 © 2012-2025 BASE, Inc. 4年前の狙いと今 ビジネス・テクノロジー・組織の変化

Slide 58

Slide 58 text

58 © 2012-2025 BASE, Inc. 4年前の狙いと今 今日は組織の話だけ

Slide 59

Slide 59 text

59 © 2012-2025 BASE, Inc. 4年前の狙いと今 今は、1チーム1モジュールではない。 オーナーがいるのは全15モジュール中10個。 残りは Feature Dev チームが担当する。 事業競争力の源泉となるモジュールは常に開発 要望がある。しかし、他はそうでもない 専門分化戦略とビジネスニーズの両者の力学を バランスさせた結果こうなった（逆コンウェイ 戦略ではない） by kawashima さん モジュール構造と一致させた組織構造 BASE株式会社 BASE Dept Product Dev Division 紹介資料 https://speakerdeck.com/base/base-productdevdivision

Slide 60

Slide 60 text

60 © 2012-2025 BASE, Inc. モジュールごとに中長期的な開発と運用の責任を担うオーナーとなる専門チームを配置 ● Platform チーム ○ 全チームが自走するための支援をする責任を持つ ○ 結果的に認証などの汎用サブドメインのオーナーとして動く傾向がある ● モジュールオーナーのチーム（Cart Team etc.） ○ 事業競争力の源泉となるコアドメインや周辺を専門的に見て、PDCAを回す ■ 事業競争力の源泉 =コアモジュール = ビジネス上の頻繁な変更要求 = 頻繁な改修 ○ 対象モジュールの中長期的な開発・運用の質に責任を持つ ● Feature Dev チーム ○ モジュールオーナーではなく複数のモジュールを横断して新機能開発を行う ○ その時のビジネスニーズを素早く満たすことに責任を持つ ○ 傾向として支援サブドメインに近い場所での活動が多い ○ PdM、デザイナーと協業して機能開発をする 4年前の狙いと今

Slide 61

Slide 61 text

61 © 2012-2025 BASE, Inc. 4年前の狙いと今 Platform Team Feature Dev Team Cart Team etc. 汎用サブドメイン が多め モジュールオーナー 支援サブドメイン が多め コアドメイン モジュールオーナー モジュールごとに中長期的な開発と運用の責任を担うオーナーとなる専門チームを配置

Slide 62

Slide 62 text

62 © 2012-2025 BASE, Inc. 4年前の狙いと今 （注）コアモジュール = コアドメイン とは言えるものの、 支援・汎用サブドメインは このモジュールがそれだ と言えるわけではない

Slide 63

Slide 63 text

63 © 2012-2025 BASE, Inc. 4年前の狙いと今 組織的な変化に対応する

Slide 64

Slide 64 text

64 © 2012-2025 BASE, Inc. 4年前の狙いと今 もっと詳しい話は アーキテクトが いつか紹介してくれるはず

Slide 65

Slide 65 text

65 © 2012-2025 BASE, Inc. ○ モジュラーモノリス ■ モノリス上のコードベースの巨大化、古いテクノロジーから移行・脱却できた ■ トラフィックの急増 ● → モジュールオーナーが責任を持つ体制に ■ 組織拡大によるアウトプット量の低下 ● → さらにチームが増えてもアウトプットを出せる体制 ○ 組織的学習 ■ 技術（How）のPDCAが回っているチーム = モジュールオーナーであるチーム ■ プロダクトの（What）PDCAを回すチーム = モジュールオーナーではないチーム ● ビジネス上の「いま・最も・重要な」領域の開発要望に素早く答える ● 機能が市場に刺さらないと開発が継続しないため、技術の学習サイクルは回せないこ ともある 4年前の狙いと今 まとめ

Slide 66

Slide 66 text

66 © 2012-2025 BASE, Inc. 4年前の狙いと今 ● Q. どのようにモジュールの境界線を引きましたか？ ○ イベントストーミングの後にpivotイベント（不可逆的な変化を引き起こすイベント）を 特定し、コアの部分とそうでない部分を分けた。ただし、線引きはどうしても恣意的に なるため、他社のECの区分を参考にするなど独自なものにならないように調査した ● Q. 開発後、モジュールの引き直しは行われましたか？ ○ 機能追加時どのモジュールに書くべきかわかりづらい場合は、Platformチームに相談し ているため大きく誤ることはない。ただイベントストーミングや境界の再考をすると気 づくことはあるかもしれない（が、コア以外はケアしすぎなくてもいいという温度感） ● Q. デプロイについてもう少し詳しく教えてください ○ モジュラーモノリスのコードを1つのDockerイメージとしてビルドし、管理画面や決済 など、各領域ごとのECSにデプロイしている。管理画面では決済モジュールのコードは全 く呼ばれないということもある 発表後に質問頂いたことの Q&A

Slide 67

Slide 67 text

67 © 2012-2025 BASE, Inc. まとめ We are hiring. https://binc.jp/jobs

Slide 68

Slide 68 text

68 © 2012-2025 BASE, Inc. まとめ ご清聴ありがとうございました