Upgrade to Pro — share decks privately, control downloads, hide ads and more …

絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ | LayerX

mosa
March 15, 2022

絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ | LayerX

業務フローをなめらかにするために絡み合う複数プロダクトに、マイクロサービスならどう向き合うかの話です。LayerXのバクラクシリーズの話です。

完璧な設計&アプローチとかではなく、現実にあったケーススタディとして、優しく見ていただけると幸いです。

mosa

March 15, 2022
Tweet

More Decks by mosa

Other Decks in Technology

Transcript

  1. Confidential © 2022 LayerX Inc.
    1
    絡み合うSaaSプロダクトの
    マイクロサービスアーキテクチャ
    2022/03/15
    @mosa_siru
    SaaS.tech #1

    View Slide

  2. Confidential © 2022 LayerX Inc.
    2
    これはなに
    ● 業務フローをなめらかにするために絡み合う複数プロダクトに、
    マイクロサービスならどう向き合うかの話です。
    ● 完璧な設計&アプローチとかではなく、現実にあったケーススタディと
    して、優しく⾒ていただけると幸いです。
    ● めちゃくちゃボリューミーです、すいません…

    View Slide

  3. Confidential © 2022 LayerX Inc.
    3
    ⾃⼰紹介
    榎本 悠介 @mosa_siru
    ・LayerX取締役 SaaS事業部⻑
    ・プロダクト/エンジニアチームをリード
    ・創業時CTO。新規事業、新規プロダクトをひたすらつくるマン
    ・前線でプロダクト仕様考えまくってコードかきまくってます

    View Slide

  4. Confidential © 2022 LayerX Inc.
    4
    ⽬次
    1. プロダクト紹介
    2. 基本の構成図と考え⽅
    3. マイクロサービスのケーススタディ(循環参照を避ける話)
    4. マイクロサービスのケーススタディ(レプリケーション)
    5. アーキテクチャ再考
    6. まとめ

    View Slide

  5. Confidential © 2022 LayerX Inc.
    5
    1. プロダクト紹介

    View Slide

  6. Confidential © 2022 LayerX Inc.
    6
    2021/01から、3つのプロダクトを順次展開(どれも単体で便利︕)
    特に今回、
    この2つに注⽬

    View Slide

  7. Confidential © 2022 LayerX Inc.
    7
    AI OCRによる⾃動読取
    仕訳の⾃動⼊⼒補完・振込データ⾃動⽣成
    会計システムとシームレスに連携
    AI OCRによる稟議の⾃動下書・申請補助
    購買申請との紐付けで予算管理
    Slack連携でSlackで承認が完結
    めちゃくちゃ便利な
    請求書処理プロダクト
    めちゃくちゃ便利な
    汎⽤ワークフロー(申請&承認)プロダクト

    View Slide

  8. Confidential © 2022 LayerX Inc.
    8
    企業A 企業B
    売り⼿・受注者 買い⼿・発注者
    請求書を発⾏
    請求書を受け取り
    会計・⽀払処理
    バクラク請求書とは
    受け取った請求書の処理を効率化するサービスです

    View Slide

  9. Confidential © 2022 LayerX Inc.
    9
    Before バクラク請求書
    ✓ 請求書を⾒ながらシステムに⼿⼊⼒が多い。⼊⼒ミスも多い。
    ✓ 前⽉の仕訳を確認しながら、仕訳を切っていて⼤変。
    ⼿⼊⼒・ミス
    回収漏れ
    ✓ 現場が請求書を上げ忘れる。取引先が請求書を送ってこない。
    ✓ 請求書の抜け漏れチェックが⼤変。
    稟議・統制
    ✓ 現場が上げる⽀払依頼が遅い。申請が間違っている。
    ✓ 請求書だけ⾒ても、⽀払っていいかわからない。請求書と稟議が紐付いてい
    ない。(紙で申請と請求書がまわってくる…)
    今回、ここに
    フォーカス当てます

    View Slide

  10. Confidential © 2022 LayerX Inc.
    10
    After バクラク請求書
    ✓ AI-OCRで請求書情報を⾃動⼊⼒
    ✓ 仕訳の⾃動⼊⼒補完・振込データ⾃動作成
    ✓ 回収状況レポートで回収漏れを確認
    ✓ 回収催促機能で、請求書をURLで回収可能
    ✓ 稟議をOCRで⾃動⼊⼒。現場でミスや負担削減
    ✓ 請求書と稟議の紐付けでかんたん確認
    ⼿⼊⼒・ミス
    回収漏れ
    稟議・統制
    今回、ここに
    フォーカス当てます

    View Slide

  11. Confidential © 2022 LayerX Inc.
    11
    回収 稟議・承認 仕訳・⽀払・消込 保管
    各プロセスの⾮効率を解消し、⼀気通貫の業務に
    ✓抜け漏れ確認
    ✓請求書催促
    ✓AI OCRで申請補助
    ✓購買申請で予算統制
    ✓slackでラクラク承認
    ✓AI OCRで⾃動読取
    ✓仕訳データの⾃動作成
    ✓⽀払データ⾃動作成
    ✓電⼦帳簿保存法対応
    データを
    ⾃動同期
    バクラクシリーズで⼀気通貫の業務プロセスのデジタル化が可能

    View Slide

  12. Confidential © 2022 LayerX Inc.
    12
    ここだけおさえておいて欲しいポイント︕
    ● 経理に請求書だけ来ても、経理は会社の全てを把握しているわけではないので、払っていい
    かわからなかったりするよ
    ○ 上⻑がその⽀払を承認していたか、元の”⽀払申請”(請求書がきたので払ってくださ
    い申請)を⾒る必要があるよ
    ● でも承認プロセスと請求書処理業務は普通「分断」されているから、その紐付けが⼤変だよ
    ○ 例︓承認された⽀払申請の内容を、プリントアウトして経理に渡している
    ● バクラク申請とバクラク請求書は、そこが連携されているのがポイントだよ
    ○ ⽀払申請がされると、バクラク請求書側に請求データが作られるよ
    (単体で便利なプロダクトたちだけど、2つ合わさるとさらに便利なんだよ)

    View Slide

  13. Confidential © 2022 LayerX Inc.
    13
    2. 基本の構成図と考え⽅

    View Slide

  14. Confidential © 2022 LayerX Inc.
    14
    構成図(基本形)
    各プロダクトのFrontendが裏側の専⽤APIを叩く形式。DBは共有しない。
    例︓ユーザー情報については、共通管理基盤(認証基盤)から取りにいく

    View Slide

  15. Confidential © 2022 LayerX Inc.
    15
    ⽅針
    ● SPA + Backend APIの構成 (Nuxt.js + Golang)
    ● 各プロダクトごとのマイクロサービス
    ○ 各プロダクトにPublic APIとPrivate APIがあり、裏側ではPrivate APIを
    利⽤
    ● DBはマイクロサービスをまたいで共有しない (ReadもWriteも⼀⼈)
    ● プロダクト間の循環参照は避ける(重要)
    ○ デプロイ順が意味不明になるため

    View Slide

  16. Confidential © 2022 LayerX Inc.
    16
    Why Microservices?
    ● 単体で成⽴するSaaSプロダクトは、ドメイン境界として適切に⾒えた
    ● 実際、開発チームは分かれていた&チームをスケールさせる覚悟があった
    ● 今後どんどんプロダクトを出す可能性があった
    ● 複数プロダクトを展開するSaaSの先輩たちが、モノリスからマイクロサービス
    に切り出すのに苦⼼しているのを知っていた

    View Slide

  17. Confidential © 2022 LayerX Inc.
    17
    3. マイクロサービスのケーススタディ
    (循環参照を避ける話)

    View Slide

  18. Confidential © 2022 LayerX Inc.
    18
    ここからが本題

    View Slide

  19. Confidential © 2022 LayerX Inc.
    19
    回収 稟議・承認 仕訳・⽀払・消込 保管
    各プロセスの⾮効率を解消し、⼀気通貫の業務に
    ✓抜け漏れ確認
    ✓請求書催促
    ✓AI OCRで申請補助
    ✓購買申請で予算統制
    ✓slackでラクラク承認
    ✓AI OCRで⾃動読取
    ✓仕訳データの⾃動作成
    ✓⽀払データ⾃動作成
    ✓電⼦帳簿保存法対応
    (※ 2022年1⽉~対応予定)
    データを
    ⾃動同期
    バクラクシリーズで⼀気通貫の業務プロセスのデジタル化が可能

    View Slide

  20. Confidential © 2022 LayerX Inc.
    20
    回収 稟議・承認 仕訳・⽀払・消込 保管
    各プロセスの⾮効率を解消し、⼀気通貫の業務に
    ✓抜け漏れ確認
    ✓請求書催促
    ✓AI OCRで申請補助
    ✓購買申請で予算統制
    ✓slackでラクラク承認
    ✓AI OCRで⾃動読取
    ✓仕訳データの⾃動作成
    ✓⽀払データ⾃動作成
    ✓電⼦帳簿保存法対応
    (※ 2022年1⽉~対応予定)
    データを
    ⾃動同期
    バクラクシリーズで⼀気通貫の業務プロセスのデジタル化が可能
    データを
    ⾃動同期︕︕

    View Slide

  21. Confidential © 2022 LayerX Inc.
    21
    要件(1)
    バクラク申請で⽀払申請(請求書がきたので払ってください申請)がされると、
    申請内容を元にしてバクラク請求書で請求書レコードが作られる (Write)
    申請すると、
    申請内容を元に
    請求書レコード作成
    請求書No. 111
    ⽀払⾦額: 660,000
    ⽀払期⽇: 2020-10-31
    取引先︓株式会社⽇本
    (添付ファイル付)
    申請作成画⾯

    View Slide

  22. Confidential © 2022 LayerX Inc.
    22
    要件(1)
    バクラク申請で⽀払申請(請求書がきたので払ってください申請)がされると、
    申請内容を元にしてバクラク請求書で請求書レコードが作られる (Write)

    View Slide

  23. Confidential © 2022 LayerX Inc.
    23
    要件(2)
    バクラク請求書で請求書を⾒るときは、元になった申請情報も⾒える(Read)
    (経理がパッと確認するため)

    View Slide

  24. Confidential © 2022 LayerX Inc.
    24
    要件(2)
    バクラク請求書で請求書を⾒るときは、元になった申請情報も⾒える(Read)
    (経理がパッと確認するため)

    View Slide

  25. Confidential © 2022 LayerX Inc.
    25
    ごく普通の要件感あるが、すでにプロダクト間で循環する・・・・

    View Slide

  26. Confidential © 2022 LayerX Inc.
    26
    どうするか

    View Slide

  27. Confidential © 2022 LayerX Inc.
    27
    考えた⽅法
    A. BFF / Gateway API を利⽤して、循環を避ける
    B. SPAが他プロダクトのPublic APIを叩くのを許す
    C. 必要なデータを同期してしまう

    View Slide

  28. Confidential © 2022 LayerX Inc.
    28
    (A) BFF / Gateway API を利⽤して、循環を避ける

    View Slide

  29. Confidential © 2022 LayerX Inc.
    29
    (A) BFF / Gateway API を利⽤して、循環を避ける
    ● メリット
    ○ シンプルである
    ● デメリット
    ○ 今は存在しないGateway APIが登場する
    ■ ※そもそもあるべきという説も濃厚であるが、各種事情で今からつくるの
    が簡単ではない
    ○ Gatewayがロジックを持たないなら、結局依存関係が発⽣(次ページ)

    View Slide

  30. Confidential © 2022 LayerX Inc.
    30
    Gatewayが更新制御ロジックを持たないなら、結局依存関係が発⽣
    Gateway API には 2つのマイクロサービスをまたいだ更新制御ロジックを持たせたくない。
    (ロールバック処理等をGatewayに持たせたくないため。)
    その場合、バクラク申請 => バクラク請求書の依存が発⽣する。
    この理屈だと、更新処理の起点がバラバラだと、結局循環参照が起きる可能性がある。

    View Slide

  31. Confidential © 2022 LayerX Inc.
    31
    (B) Frontend が各プロダクトのPublic APIを叩くのを許す

    View Slide

  32. Confidential © 2022 LayerX Inc.
    32
    (B) Frontend が各プロダクトのPublic APIを叩くのを許す
    ● よくある、BFFを導⼊する前のパターン。⽐較的シンプルではある
    ● 場合によっては結局依存が発⽣する(次ページ)
    ● 認証・権限まわりがカオスになりがち
    ○ 例︓バクラク申請の権限が⾜りず、バクラク請求書側で元になった申請を⾒るこ
    とができない(あるべき姿かもしれないが、混乱の元になりうる)

    View Slide

  33. Confidential © 2022 LayerX Inc.
    33
    Frontendが更新制御ロジックを持たないなら、結局依存が発⽣
    両プロダクトの更新処理をFrontendから投げるのは、トランザクション管理を考えるとおすすめ
    しない。
    backend経由にする場合、結局バクラク申請 => バクラク請求書の依存は発⽣する。(Gateway
    APIの時と同様)
    循環参照を避けるには、更新の起点を統⼀する必要がある。

    View Slide

  34. Confidential © 2022 LayerX Inc.
    34
    (C) 必要なデータを同期してしまう

    View Slide

  35. Confidential © 2022 LayerX Inc.
    35
    (C) 必要なデータを同期してしまう
    ● メリット
    ○ バクラク請求書ユーザーは、申請側の権限に依らず申請情報を⾒ることができる
    ● デメリット
    ○ データ同期の複雑性
    ○ データ不整合の危険
    ○ DBスキーマ変更時に⼤変
    これやるくらいなら、DB直参照を許した⽅が良いのではという気分にならなくもない。
    (Writeは1⼈の責任、Readは最悪複数⼈を許す)

    View Slide

  36. Confidential © 2022 LayerX Inc.
    36
    さらに要件は続く

    View Slide

  37. Confidential © 2022 LayerX Inc.
    37
    よく考えたら出てきた⾟い要件(3)
    バクラク請求書側の請求書⼀覧の検索にて、元の申請のステータス(承認済等)でフィルタしたい
    (例︓承認済の請求書だけ処理したい)

    View Slide

  38. Confidential © 2022 LayerX Inc.
    38
    これはやばい
    ● 請求書⼀覧のフィルタは、請求書の⽇付や⾦額等、あらゆる条件の掛け合わせで⾏わ
    れる。申請ステータスはその⼀部。
    ● これを最適なページング込みで実現するには、同じDBに持つしかない

    View Slide

  39. Confidential © 2022 LayerX Inc.
    39
    よく考えたら出てきた⾟い要件(4)
    バクラク請求書側で、元になった申請のデータと合わせて請求書リストをデータ出⼒したい
    請求書No 取引先名 ⾦額 元の申請No 元の申請タイトル
    #123 mosa産業 10,000 #12 ⽀払申請(mosa産業)
    #121 ymatsu⽔産 20,000 #9 ⽀払申請(ymatsu⽔
    産)
    #120 … … .,.. …

    View Slide

  40. Confidential © 2022 LayerX Inc.
    40
    これもやばい
    A. Gateway APIパターン︓ Gateway APIでCSV組み⽴てるの・・・︖
    B. Frontend パターン︓Frontでデータの組み⽴てをすることは現実的ではない。
    結局、バクラク請求書 => バクラク申請の依存が発⽣する(下図)
    これにより循環参照となる。
    C. データ同期して、同じDBに持つのがベストではという結論

    View Slide

  41. Confidential © 2022 LayerX Inc.
    41
    データ同期の実現⽅法 3つ

    View Slide

  42. Confidential © 2022 LayerX Inc.
    42
    実際は、API経由ではなく⾮同期でデータ同期する
    API経由だと
    ● 同期処理によりレスポンスが遅くなる
    ● 他サービスの障害に影響して、本来の処理(申請作成)⾃体も失敗してしまう。
    ● トランザクション境界が分かれているため、失敗時にデータ不整合がありうる
    => Queue経由でリトライ機構を⼊れ、結果整合とする。
    Private APIは
    微妙…

    View Slide

  43. Confidential © 2022 LayerX Inc.
    43
    パターン1: Push型
    必要な情報をまるっと渡し、⾮同期で更新。必要なコンポーネントも少なく、シンプル。queue
    のpayloadは太りがち。
    バクラク申請 => バクラク請求書 の依存が発⽣する。

    View Slide

  44. Confidential © 2022 LayerX Inc.
    44
    パターン2: Pull型
    申請IDのみを渡し、実体は取りにこさせる形式。queueのpayloadがシンプルで扱いやすい。
    軽微な循環参照だが、今後 バクラク申請 <= バクラク請求書 の依存(Push型と逆の依存)の⽅
    向が強くなりそうな場合、有⽤。

    View Slide

  45. Confidential © 2022 LayerX Inc.
    45
    パターン3: 仲介型
    複雑だが、専⽤のコンポーネントを仲介することで、直接的な依存を発⽣させない。

    View Slide

  46. Confidential © 2022 LayerX Inc.
    46
    パターンのまとめ
    A => B の依存 A <= B の依存 コンポーネント数
    1. Push型 強 - 少
    2. Pull型 弱 強 中
    3. 仲介型 弱 - 多
    どの依存関係を作りたいかによって、アプローチが異なる。
    => 僕らは今後どの依存関係がメインになりそうか︖
    顧客の声をもとに、将来ありそうな要件をベースに考えた。

    View Slide

  47. Confidential © 2022 LayerX Inc.
    47
    開発を進めるうちに出てきた要件(5)
    バクラク申請のサービスで、現在バクラク請求書で保持しているマスタデータを⼊⼒したい
    (例︓申請にて、どの部⾨で使われた費⽤かを⼊⼒・表⽰させたい)

    View Slide

  48. Confidential © 2022 LayerX Inc.
    48
    おそらくバクラク申請 => バクラク請求書の依存が発⽣しやすいドメインと理解
    補⾜︓今回の要件ならGateway APIがあれば依存は発⽣しないように⾒えるが、「申請⼀覧を出⼒したい」と⾔われるとやはりアウト

    View Slide

  49. Confidential © 2022 LayerX Inc.
    49
    【結論】
    依存関係の整理の結果、シンプルな「 1. Push型」にした
    A => B の依存 A <= B の依存 コンポーネント数
    1. Push型 強 - 少
    2. Pull型 弱 強 中
    3. 仲介型 弱 - 多

    View Slide

  50. Confidential © 2022 LayerX Inc.
    50
    補⾜︓データの置き場所
    ● 依存を発⽣させないために、各プロダクトから参照されやすい
    マスタデータを、そもそも別サービスに切り出す⼿もある
    ● 「どこから更新されるか」「どこから参照したくなるか」
    あらゆるユースケースを想像して、「誰の持ち物か」を考え続
    ける必要がある
    ○ 事前に決めるには、めちゃくちゃドメイン知識がいる。
    設計レベルでドメインエキスパートと相談していた。
    ● 実際、とあるマスタデータは後から最適な場所に移動させた。

    View Slide

  51. Confidential © 2022 LayerX Inc.
    51
    補⾜︓データ同期の整合性担保
    不整合をおこさないために・・・
    ● 当然リトライする
    ● データ同期ジョブについて、当然監視をする
    ● 最終的にデータに不整合がおきていないか、定期的に確認し、アラートを⾶ばしている

    View Slide

  52. Confidential © 2022 LayerX Inc.
    52
    4. マイクロサービスのケーススタディ
    (レプリケーション)

    View Slide

  53. Confidential © 2022 LayerX Inc.
    53
    他にもデータ同期が必要なデータが現れだした
    ● バクラク申請にて、他のRDBとJOINしないと、パフォーマンス的に厳しいクエ
    リが出てきた(詳細略)
    ○ (この時点でドメイン境界とは…など⾊々⾔いたいことはある⽅はいそうですが、
    まだ抑えてください)
    ● これは「申請をもとに請求書レコードをつくり、さらに申請データも同期する」
    等ではなく単純なレプリケーションで良いため、前述と異なる同期パターンが考
    えられた

    View Slide

  54. Confidential © 2022 LayerX Inc.
    54
    同期パターン1 Push型 / パターン2 Pull型 / パターン3 仲介型
    上述と同様。(下図はパターン1)

    View Slide

  55. Confidential © 2022 LayerX Inc.
    55
    パターン4︓定期Pull型
    定期実⾏して、差分のあるレコードを取得し、更新する。

    View Slide

  56. Confidential © 2022 LayerX Inc.
    56
    パターン4︓定期Pull型
    クライアントサイドは「最終更新時刻」を持っておき、「それ以降に更新された
    レコード⼀覧をくれ︕」と⾔うイメージ。
    ● メリット
    ○ パターン1-3と異なり、とりこぼしがなく、データ整合性を保ちやすい
    ● デメリット
    ○ リアルタイム性が低い
    ○ ⼀括でデータ更新されていると同期量が多い
    ○ 物理削除されたことをハンドリングするにはひと⼿間いる

    View Slide

  57. Confidential © 2022 LayerX Inc.
    57
    パターン5︓DBをまたいでレプリケーションする
    ● 例︓AWS DMS(hostをまたいで特定テーブルのレプリが可能)
    ○ 1回限りではなく、継続的なレプリケーションが可能

    View Slide

  58. Confidential © 2022 LayerX Inc.
    58
    パターン5︓DBをまたいでレプリケーションする
    ● AWS DMSを素振りしたところ、問題なくhostをまたいでレプリケーション
    された
    ● ALTERもsyncされることを確認した
    ○ ※カラムのデフォルト値, nullability, charset の変更は同期されないので注意
    ● ⼀⽅、localでの開発環境をどうするかが課題
    ● (そして同様のユースケースで使っているのを⾒たことがなく、不安)

    View Slide

  59. Confidential © 2022 LayerX Inc.
    59
    【結論】
    ● 今回のケースではデメリットを許せたため、「パターン4︓定期Pull型」とした
    ● やはりユースケースによって最適な⼿段は変わる

    View Slide

  60. Confidential © 2022 LayerX Inc.
    60
    5. アーキテクチャ再考

    View Slide

  61. Confidential © 2022 LayerX Inc.
    61
    そして現在、まだまだ増え続ける連携ニーズ
    「バクラク請求書のファイルをバクラク電⼦帳簿保存に連携したい」
    「バクラク申請のファイルをバクラク電⼦帳簿保存に連携したい」
    「バクラク電⼦帳簿保存にあがったファイルを、バクラク申請に使えないか」

    View Slide

  62. Confidential © 2022 LayerX Inc.
    62
    俺たちは⼀体何と戦っているんだ︖

    View Slide

  63. Confidential © 2022 LayerX Inc.
    63
    そもそもドメイン境界間違えてない︖
    モノリスじゃだめなの︖

    View Slide

  64. Confidential © 2022 LayerX Inc.
    64
    実際やってみた

    View Slide

  65. Confidential © 2022 LayerX Inc.
    65
    モジュラモノリス化のトライ
    ● mosaがマイクロサービスに発狂し、1-2週間集中して取り組んだ。
    ● せっかく分かれているDBは⼤統⼀せずに、モジュラモノリスっぽくやるの
    を検討した

    View Slide

  66. Confidential © 2022 LayerX Inc.
    66
    当初考えていたメリット
    1. 循環参照問題からの解放
    2. データ同期と整合性チェック、Txまたぎの必要がなくなる
    3. コード共有ができる、無駄なPrivate API開発がなくなる

    View Slide

  67. Confidential © 2022 LayerX Inc.
    67
    結論︓撤退した

    View Slide

  68. Confidential © 2022 LayerX Inc.
    68
    撤退の理由
    ● 循環参照問題からの解放はされなかった。
    ○ モジュラモノリス内で循環依存を避けるために、結局同じことを考え
    る必要があった
    ○ 例︓申請情報をembedする請求書struct があると、package依存が発

    ○ コンポーネント間の複雑さを、そのままコード間の複雑さにおしこめ
    た印象だった。
    ● DBが分かれている時点で、Txまたぎと不整合リスクは残った
    ● 組織のスケールという流れに逆⾏している
    ● 思ったより共有されるロジックはなかった
    ● コードの⾒通しが悪くなった。書いていて楽しくなくなった(フィーリング)

    View Slide

  69. Confidential © 2022 LayerX Inc.
    69
    本当に試すべきは真のモノリス & DBの統⼀化だったか
    ● 仮にモジュラモノリスがうまく⾏くなら、今のマイクロサービスでもうま
    くいくはず。
    ● やるならDBも統⼀、循環依存上等な完全なモノリス化だが、今のメリット
    を完全に捨てることになる。モジュラモノリスでない以上、戻ることも茨
    の道。ゼロベースならさておき、今からやるには…。

    View Slide

  70. Confidential © 2022 LayerX Inc.
    70
    あらためて、今の構成の
    メリットは何か︖

    View Slide

  71. Confidential © 2022 LayerX Inc.
    71
    連携の設計は難しいが、マイクロサービスのメリットを享受しているのも事実
    ● 各位が⾃律して動き、ファクトとして爆速で開発できて
    おり、運⽤もできている
    ○ いまも現在進⾏形で新しいプロダクトを開発しよ
    うとしている
    ● 他にも、OCR基盤/認証基盤/タイムスタンプ機構などプ
    ロダクトによらないマイクロサービスもあり、効率化の
    恩恵を感じている
    ● そもそも単体で成⽴しているプロダクトであり、「⼀部
    でもデータ連携(の可能性)があるから分けるべきでな
    い」というのもどうなのか
    ○ 今後新しいプロダクト群も全部モノリスにするの
    か︖
    ● 新しいプロダクトでは新しい開発⼿法を試すことができ、
    確実にチームに知⾒がたまっている

    View Slide

  72. Confidential © 2022 LayerX Inc.
    72
    6. まとめ

    View Slide

  73. Confidential © 2022 LayerX Inc.
    73
    まとめ
    ● 複数プロダクトで業務フローをなめらかにするSaaSは、ドメイン境界の設
    定が単純ではない
    ○ 適切な切り⽅を知るには、深いドメイン知識が必要で、後からわかる
    ことも多い
    ● 連携部分とデータの置き場所は、設計⼒が極めて問われ、ユースケースに
    依存する
    ● 割り切って最初からモノリスにすることは⼗分ありうる。⼀⽅、先輩⽅が
    後から切り出すのに苦労しているのも事実
    ● モジュラモノリスも結局依存関係と戦うことになると実感

    View Slide

  74. Confidential © 2022 LayerX Inc.
    74
    We are Hiring︕
    LayerXでは、顧客と向き合い、最⾼の体験と最適な設計を
    両⽴できるエンジニアを求めています︕
    https://jobs.layerx.co.jp/

    View Slide