Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

現場から学ぶシステム設計:座談会 / genba sekkei vol 1

現場から学ぶシステム設計:座談会 / genba sekkei vol 1

2021年10月27日に実施した座談会のスライドです。
https://modeling-how-to-learn.connpass.com/event/227432/

より良い設計を模索しながらプロダクト開発に取り組んでいる3社が集まり、現場の悩みをベースに設計について議論しました。

集約のエンティティ

October 27, 2021
Tweet

More Decks by 集約のエンティティ

Other Decks in Programming

Transcript

  1. タイムテーブル 時間 内容 19:00 - 19:05 オープニング 19:05 - 19:20

    各社紹介 事業、プロダクト 紹介 19:20 - 19:40 座談会 前半戦 3ヶ月前 悩みと振り返り 19:40 - 20:20 座談会 後半戦 最近 悩み 20:20 - 20:40 意見交換
  2. 今日 きっかけ • アルプで 社内で定期的に設計について相談する会を実施 • 今年7月にLegalForceさんShowcase Gigさんと一緒に議論する会を実施 • そして今日

    ◦ 前回 学びを現場に持ち帰って、そ 後 アップデートを発表する場 ◦ また、新しい設計 悩みについて議論する場
  3. 本日 メンバー 田坂さん 鈴木さん daiさん 宮腰さん 田宮さん 荒木さん 集約 エンティティ

    竹尾 男爵 増田さん @masuda220 @yuuuutsk @suzushin54 @dskst9 @dnskimox @showmant_ @pictiny @A_Tree @miyakosis
  4. 契約 締結前 契約書レビュー 品質向上と 効率化を実現する AI契約審査プラットフォーム 契約 締結後 締結済み 契約書を自動で

    データベース化する クラウド契約書管理システム 企業向けに契約リスクを制御する2つ 製品を提供しています
  5. 私たち 経済活動 、さまざまな契約で成り立っ ています。それ 同時に契約リスクが潜んでいる ということ。 LegalForce 、最新 テクノロジーと法務 知見

    を組み合わせて契約リスクを可視化し、制御可能 な状態へ導きます。 あるべき権利が適切に守られ、不測 事態が防が れるために。そして、より豊かで信頼に満ちた経済 社会を目指します。
  6. 値オブジェクトを実装する時 ルール • 外部I/Oが発生しない操作だよ • 依存なし 設計にして (ドメイン・オブジェクト同士 🙆) •

    ユースケースを元に概念整理を行った上で実装しよう ◦ 計測、説明、判定など 振る舞い 実装 • 不変性、比較、等々教科書に載ってる制約
  7. Scalebase Connect for Salesforce (SFA) 開発 課題 • 技術セットが大きく異なる ◦

    Apex、LWC、、、 • Salesforce Application 開発者 採用が難しい • コアシステム ドメインを流用した実装があり、負債化している ◦ 請求から見積を作っている トライ • 社内 Webエンジニアがコンバートしやすい設計へリファクタし内製化へ • サブシステム用 ドメインを切っていく ◦ 見積にフィットするドメインモデルをコアシステムに作る (予定)
  8. 行動履歴 注文履歴 / 会計履歴 ID API群 マスターデータ操作系 標準API 注文 会計

    決済 etc... 店舗,商品参照 PF立ち上げ 中で悩んだ整合性 話 我々 作っているシステム O:der Platformを端的に表すと 飲食に関する価値あるマスターデータ とIDを軸としたAPI群 PF API プロダクトが使いやすいように、より 高凝集かつ疎結合な必要がある 飲食 プロダクトに 多様な提供手法がある ・イートイン、テイクアウト、デリバリーなど ・プロダクト毎 機能 primitiveに見ると概 同じ 価値あるマスターデータ 店舗構造 / メニュー構造 イベント通知 会計ステータス変更通知 注文ステータス変更通知 Product ※ 価値あるマスターデータと 、信憑性がありビジネス活用できたり、ユーザに恩恵 あるデータ
  9. 注文を例に整合性について考える • 注文 会計や決済 事実と一対一 関係 • どれかが欠けた状態 (不整合)だと店舗で 注文オペレーションが出来ない

    で 不整合を解消する必要 がある PF立ち上げ 中で悩んだ整合性 話 注文 会計 決済 完了 メール 注文 中 処理 内訳 (※テイクアウト ケース)
  10. Product Backend 2. 注文&決済 記録 5. 決済 4.会計 7. 調理予約+印刷

    (非同期pub/sub) 9. 成功 オフライン連携 APIs 1. 注文&決済 Platform Basic APIs 3. 仮注文 6. 注文確定 8. メール配信 7-1. 調理予約 記録 7-2. 印刷 決済代行(他社) 結合度を下げるため ビジネスロジックが非同期 で済むも 実装も 非同期にすることも 5-1. 決済 PF立ち上げ 中で悩んだ整合性 話 注文 整合性:分散トランザクションをした時 一連 手続きにおいて、処理がサーバで別れている時 ※ 特にPF事業をしていると遭遇しやすい どんな時分散トランザクションになる?
  11. Product Backend 2. 注文&決済 記録 失敗すると不整合が発生するケースもある • 様々なところで失敗するケースがある 整合性解消 責務

    • プロダクトによって整合性 定義が違う で、不整 合 解消責務 プロダクト側に おくべき • しかし実現コスト こちらもある程度高い ◦ 全体設計やアプリケーションコード 設計 にどう影響させるかが悩み所 5. 決済 4.会計 7. 調理予約+印刷 (非同期pub/sub) 9. 成功 オフライン連携 APIs 1. 注文&決済 Platform Basic APIs 3. 仮注文 6. 注文確定 8. メール配信 7-1. 調理予約 記録 7-2. 印刷 決済代行(他社) 5-1. 決済 失 敗 失 敗 前回 勉強会で お悩み PF立ち上げ 中で悩んだ整合性 話 注文 整合性:分散トランザクションをした時 どこかで失敗した時
  12. そもそもだけど、整 合性ってほんとに 大事な ? 増田さん 他に大事なこともっ とあるんじゃない? 私たち 確かに。。 不整合を防ぐ方法に固執

    していた。。 PF立ち上げ 中で悩んだ整合性 話 そもそも 失敗すると不整合が発生するケースもある • 様々なところで失敗するケースがある 整合性解消 責務 • プロダクトによって整合性 定義が違う で、不整 合 解消責務 プロダクト側に おくべき • しかし実現コスト こちらもある程度高い ◦ 全体設計やアプリケーションコード 設計 にどう影響させるかが悩み所 前回 勉強会で お悩み どこかで失敗した時
  13. 結論 一連 処理において不整合が起きた時 機能的に使えていれ 良く、解消すべき不整合があっ たときに解消できれ 問題ない! 大事なこと • 不整合に気づけること

    • 不整合を解消できること ◦ 手動や必要に応じて自動 実践したこと👍 • 不整合に気づけること ◦ 失敗時 アラート • 不整合が起きる ケース 洗い出し ◦ どんな時にど ように 不整合を解消すべきかを整理 • 不整合を解消できること ◦ PF側で不整合解消 API 提供 ▪ 各種取り消しAPI ▪ 一部自動解消job ◦ プロダクト側で 手動解消機能 実装 PF立ち上げ 中で悩んだ整合性 話 そもそも質問を受けて そもそもだけど、整 合性ってほんとに 大事な ? 増田さん 他に大事なこともっ とあるんじゃない? 私たち 確かに。。 不整合を防ぐ方法に固執 していた。。
  14. マイクロサービス(風) 構成 web service application logic (server) AI レビュー テキスト

    検索 ・・・ request 分散トランザクション 実装していないため、 サーバ間でデータ不整合が起きるケースがある → 次 ページ以降で「ユーザ作成」を例に説明 R&D team 製品開発 team
  15. ユーザ作成 • ユーザ情報 LegalForce(DB) 登録 • Auth0 (認証サービス) ユーザ作成 •

    Intercom (ユーザーサポートチャットサービス) ユーザ作成 • Welcome メール送信 トランザクション制御できない上記操作 全てを正常に完了する必要がある
  16. ユーザ作成(途中で失敗) • ✓ユーザ情報 DB登録 (成功) • ✓Auth0 (認証サービス) ユーザ作成 (成功)

    • ☓Intercom (ユーザーサポートチャットサービス) ユーザ作成 (失敗) • Welcome メール送信 途中で失敗した場合に 整合性を保つために作成済み 情報を削除していく
  17. ユーザ作成(ロールバックに失敗) • ✓ ☓ユーザ情報 DB登録→削除に失敗 • ✓✓Auth0 (認証サービス) ユーザ作成→削除に成功 •

    ☓ Intercom (ユーザーサポートチャットサービス) ユーザ作成 • Welcome メール送信 ロールバック処理で失敗した場合に不整合が発生してしまう・・・
  18. トランザクション制御できない操作を どう保証するか • 基本的に ログにエラー情報を出力して手動でリカバリ対応する? ◦ 顧客が増えると対応工数がそれに比例する ◦ でも直前 ユーザー作成に成功している

    で、削除に失敗するケー ス 少なそうな でこれでいいかな・・・ • ロールバック処理 成功するまで無限に繰り返す? ◦ ちょっと強引すぎるかも ◦ 1日1回 定期リカバリバッチを作っておき、リカバリ対象データを登 録しておく
  19. 考えられるアプローチ 1. 1つ システムとして扱う ◦ イートイン、テイクアウトを統合 ▪ pros: ロジック 重複を排除できる

    ▪ cons: DDDと 真逆 アプローチ😕 2. モジュール分割 観点を変える ◦ サブドメイン[注文] と [商品] ◦ テイクアウトやイートイン モジュールから呼び出す ▪ pros: モデル 重複を排除できる ▪ cons: 正しく分割する が難しい • 商品モデルに「イートイン」専用 属性・振る舞いができたら?
  20. マイクロサービスで予想される問題 (Alp) • 我々 モジュラモノリスで、まだマイクロサービスで ないが… • マイクロサービスにするとコアドメインをみんな触ることにならないか? ◦ Scalebaseでいうと、カタログ・契約・請求

    依存関係がなかなか切れない ◦ 契約に影響 ない機能開発が難しい • こ ような状況でマイクロサービス化 恩恵を受けられるか? ◦ 何かうまい切り方 あるだろうか? • ドメインコンテキストごと チームを組織して、認知負荷を下げたい ◦ ドメイン知識を個人で なくチームに貯めたい ◦ ど チームも契約について知る必要がある状況になりそう。これを回避するに ?