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

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

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

1. 現場から学ぶ システム設計 座談会 2021.10.27
2. タイムテーブル 時間 内容 19:00 - 19:05 オープニング 19:05 - 19:20 各社紹介 事業、プロダクト 紹介 19:20 - 19:40 座談会 前半戦 3ヶ月前 悩みと振り返り 19:40 - 20:20 座談会 後半戦 最近 悩み 20:20 - 20:40 意見交換
3. 今日 テーマ 現場で悩んだ設計について相談・議論を通じて理解を深めよう
4. 今日 きっかけ • アルプで 社内で定期的に設計について相談する会を実施 • 今年7月にLegalForceさんShowcase Gigさんと一緒に議論する会を実施 • そして今日 ◦ 前回 学びを現場に持ち帰って、そ 後 アップデートを発表する場 ◦ また、新しい設計 悩みについて議論する場
5. 本日 メンバー 田坂さん 鈴木さん daiさん 宮腰さん 田宮さん 荒木さん 集約 エンティティ 竹尾 男爵 増田さん @masuda220 @yuuuutsk @suzushin54 @dskst9 @dnskimox @showmant_ @pictiny @A_Tree @miyakosis
6. 各社紹介
14. Mission 全て 契約リスクを 制御可能にする。 ※契約リスク と 契約に含まれる「不利な条件」や「法 令違反」を指す
15. 契約書 作成・審査 法務担当者 業務時間 平均4割を占める LegalForce Conference 2020に参加した 法務担当者に対する調査より (n=883)
16. 契約 締結前 契約書レビュー 品質向上と 効率化を実現する AI契約審査プラットフォーム 契約 締結後 締結済み 契約書を自動で データベース化する クラウド契約書管理システム 企業向けに契約リスクを制御する2つ 製品を提供しています
17. 私たち 経済活動 、さまざまな契約で成り立っ ています。それ 同時に契約リスクが潜んでいる ということ。 LegalForce 、最新 テクノロジーと法務 知見 を組み合わせて契約リスクを可視化し、制御可能 な状態へ導きます。 あるべき権利が適切に守られ、不測 事態が防が れるために。そして、より豊かで信頼に満ちた経済 社会を目指します。
18. @j5ik2o氏を迎えオンラインで毎 週ドメインモデリング勉強会を 行っています ※画像 イメージです ※写真に@j5ik2o氏 含 まれていません ※写っている 全員弊 社エンジニアです
21. これから 「あたりまえ」を生み出すプラットフォーム 店舗 新しい提供態と顧客体験をつくりだし、 店舗における省人化や顧客満足度向上を同時に実現しています。
23. 各種POS機器 店舗オペレーション 店舗内注文管理デバイス 注文伝票出力プリンタ 注文表示サイネージ オフライン オンライン オフラインとオンラインが融合する それ インターネット 開発で 経験すること できない課題があります。
24. 座談会
25. 前回 テーマと振り返り
26. 値オブジェクト 導入 LegalForce 田宮
27. 肥大化するユースケース とりあえずやったこと • Mixinを使った手続き処理 共通化 共通処理をまとめること できたけど、今度 テストが肥大化。 些細な改修でも大幅なテスト改修が必要になっていた。。。 散ら った手続き型 コードを責務毎にいい感じにまとめられないかなぁ 、とここら辺で真剣に考え始める
28. いや、待てよ 🤔 利用しているHanami（弊社が利用しているフレームワーク）がドメイ ン層を提供してくれてるよ 🤔🤔🤔 ※Hanami クリーンアーキテクチャを実践しているフレームワークです。依存関係を意 識した開発ができます。DIP!
29. 問題を掘り下げてみた 永続化層と関連があるオブジェクトをとにかく神聖化 永続化層（技術的なレイヤ）とドメインオブジェクトを切り離した設計ができてなかった 技術的なレイヤを切り離した設計に踏み出す。 →値オブジェクト 導入 → 継続的なリファクタリングで豊かなモデルを実装
30. 値オブジェクトを実装する時 ルール • 外部I/Oが発生しない操作だよ • 依存なし 設計にして （ドメイン・オブジェクト同士 🙆） • ユースケースを元に概念整理を行った上で実装しよう ◦ 計測、説明、判定など 振る舞い 実装 • 不変性、比較、等々教科書に載ってる制約
31. 値オブジェクトを導入して良かったこと • 実装が楽しくなった • Mixinを使った共通化より粒度が細かい で、再利用価値が増した • よりセキュアなアプリケーションが実装できるようになった • 名前空間を意識した設計（context境界）を実践し、他チームと コンフリクトを減ら せると期待
32. アルプ 課題とトライ
33. Scalebase Connect for Salesforce (SFA) 開発 課題 • 技術セットが大きく異なる ◦ Apex、LWC、、、 • Salesforce Application 開発者 採用が難しい • コアシステム ドメインを流用した実装があり、負債化している ◦ 請求から見積を作っている トライ • 社内 Webエンジニアがコンバートしやすい設計へリファクタし内製化へ • サブシステム用 ドメインを切っていく ◦ 見積にフィットするドメインモデルをコアシステムに作る (予定)
34. PF立上げ 中で悩んだ整合性 話 Showcase Gig Inc. PF開発チーム TL 田坂
35. 行動履歴 注文履歴 / 会計履歴 ID API群 マスターデータ操作系 標準API 注文 会計 決済 etc... 店舗,商品参照 PF立ち上げ 中で悩んだ整合性 話 我々 作っているシステム O:der Platformを端的に表すと 飲食に関する価値あるマスターデータ とIDを軸としたAPI群 PF API プロダクトが使いやすいように、より 高凝集かつ疎結合な必要がある 飲食 プロダクトに 多様な提供手法がある ・イートイン、テイクアウト、デリバリーなど ・プロダクト毎 機能 primitiveに見ると概 同じ 価値あるマスターデータ 店舗構造 / メニュー構造 イベント通知 会計ステータス変更通知 注文ステータス変更通知 Product ※ 価値あるマスターデータと 、信憑性がありビジネス活用できたり、ユーザに恩恵 あるデータ
36. 注文を例に整合性について考える • 注文 会計や決済 事実と一対一 関係 • どれかが欠けた状態 (不整合)だと店舗で 注文オペレーションが出来ない で 不整合を解消する必要 がある PF立ち上げ 中で悩んだ整合性 話 注文 会計 決済 完了 メール 注文 中 処理 内訳 （※テイクアウト ケース）
37. 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事業をしていると遭遇しやすい どんな時分散トランザクションになる？
38. Product Backend 2. 注文＆決済 記録 失敗すると不整合が発生するケースもある • 様々なところで失敗するケースがある 整合性解消 責務 • プロダクトによって整合性 定義が違う で、不整 合 解消責務 プロダクト側に おくべき • しかし実現コスト こちらもある程度高い ◦ 全体設計やアプリケーションコード 設計 にどう影響させるかが悩み所 5. 決済 4.会計 7. 調理予約＋印刷 (非同期pub/sub) 9. 成功 オフライン連携 APIs 1. 注文&決済 Platform Basic APIs 3. 仮注文 6. 注文確定 8. メール配信 7-1. 調理予約 記録 7-2. 印刷 決済代行(他社) 5-1. 決済 失 敗 失 敗 前回 勉強会で お悩み PF立ち上げ 中で悩んだ整合性 話 注文 整合性：分散トランザクションをした時 どこかで失敗した時
39. そもそもだけど、整 合性ってほんとに 大事な ？ 増田さん 他に大事なこともっ とあるんじゃない？ 私たち 確かに。。 不整合を防ぐ方法に固執 していた。。 PF立ち上げ 中で悩んだ整合性 話 そもそも 失敗すると不整合が発生するケースもある • 様々なところで失敗するケースがある 整合性解消 責務 • プロダクトによって整合性 定義が違う で、不整 合 解消責務 プロダクト側に おくべき • しかし実現コスト こちらもある程度高い ◦ 全体設計やアプリケーションコード 設計 にどう影響させるかが悩み所 前回 勉強会で お悩み どこかで失敗した時
40. 結論 一連 処理において不整合が起きた時 機能的に使えていれ 良く、解消すべき不整合があっ たときに解消できれ 問題ない! 大事なこと • 不整合に気づけること • 不整合を解消できること ◦ 手動や必要に応じて自動 実践したこと👍 • 不整合に気づけること ◦ 失敗時 アラート • 不整合が起きる ケース 洗い出し ◦ どんな時にど ように 不整合を解消すべきかを整理 • 不整合を解消できること ◦ PF側で不整合解消 API 提供 ▪ 各種取り消しAPI ▪ 一部自動解消job ◦ プロダクト側で 手動解消機能 実装 PF立ち上げ 中で悩んだ整合性 話 そもそも質問を受けて そもそもだけど、整 合性ってほんとに 大事な ？ 増田さん 他に大事なこともっ とあるんじゃない？ 私たち 確かに。。 不整合を防ぐ方法に固執 していた。。
41. 最近 悩み
42. サーバ間 トランザクション制御 LegalForce 宮腰
43. マイクロサービス(風) 構成 web service application logic (server) AI レビュー テキスト 検索 ・・・ request 分散トランザクション 実装していないため、 サーバ間でデータ不整合が起きるケースがある → 次 ページ以降で「ユーザ作成」を例に説明 R&D team 製品開発 team
44. ユーザ作成 • ユーザ情報 LegalForce(DB) 登録 • Auth0 (認証サービス) ユーザ作成 • Intercom (ユーザーサポートチャットサービス) ユーザ作成 • Welcome メール送信 トランザクション制御できない上記操作 全てを正常に完了する必要がある
45. ユーザ作成（途中で失敗） • ✓ユーザ情報 DB登録 (成功) • ✓Auth0 (認証サービス) ユーザ作成 (成功) • ☓Intercom (ユーザーサポートチャットサービス) ユーザ作成 (失敗) • Welcome メール送信 途中で失敗した場合に 整合性を保つために作成済み 情報を削除していく
46. ユーザ作成（ロールバックに失敗） • ✓ ☓ユーザ情報 DB登録→削除に失敗 • ✓✓Auth0 (認証サービス) ユーザ作成→削除に成功 • ☓ Intercom (ユーザーサポートチャットサービス) ユーザ作成 • Welcome メール送信 ロールバック処理で失敗した場合に不整合が発生してしまう・・・
47. トランザクション制御できない操作を どう保証するか • 基本的に ログにエラー情報を出力して手動でリカバリ対応する？ ◦ 顧客が増えると対応工数がそれに比例する ◦ でも直前 ユーザー作成に成功している で、削除に失敗するケー ス 少なそうな でこれでいいかな・・・ • ロールバック処理 成功するまで無限に繰り返す？ ◦ ちょっと強引すぎるかも ◦ １日１回 定期リカバリバッチを作っておき、リカバリ対象データを登 録しておく
48. 複数 境界づけられたコンテキストにおける 共通ロジック 扱いについて Showcase Gig Inc. プロダクト開発チーム TL 鈴木
49. Showcase Gig - 最近 悩み 複数 境界づけられたコンテキストがあるとき 共有したいモデルやユースケース ど ように扱うべきか
50. 用語 確認 境界づけられたコンテキスト • ドメイン 問題を技術的ソリューションで解決するも • 巨大なモデルを構築しないためにユビキタス言語 境界に従 い分割
51. そ 悩み おかしい で ないか？ ・・・と思う人もいるかもしれません モデルを定義・適用する境界を明示的に示した結果 作られるも が境界づけられたコンテキストなんだから、 共有したいユースケースやモデルなんてある方がおかしい で 🤔
52. 境界づけられたコンテキスト 例 実際に 特定 ドメイン 問題解決に複数システムが 関わることがある 『実践ドメイン駆動設計』 第2章 ドメイン、サブドメイン、境界づけられたコンテキスト より
53. 私たち システム （プロダクトバックエンド） ※実際 システムから表現を 変更・簡略化しています ビジネス ルールが 変わる単位で分割 ドメイン モバイルオーダー
54. 私たち システム （プロダクトバックエンド） ※実際 システムから表現を 変更・簡略化しています
55. 課題 再確認 複数 境界づけられたコンテキストがあるとき 共有したいモデルやユースケース ど ように扱うべきか
56. 課題 具体例 注文モデル コンテキスト ごとに異なる 注文商品モデル 共通 ドメインモデルや それを利用する処理が重複しがち
57. モジュラモノリスとして実装
58. 単純にコードを流用すると 異なるコンテキスト ユースケースを呼び出してしまうことに モジュール化と 🤔
59. 考えられるアプローチ 1. 1つ システムとして扱う ◦ イートイン、テイクアウトを統合 ▪ pros: ロジック 重複を排除できる ▪ cons: DDDと 真逆 アプローチ😕 2. モジュール分割 観点を変える ◦ サブドメイン[注文] と [商品] ◦ テイクアウトやイートイン モジュールから呼び出す ▪ pros: モデル 重複を排除できる ▪ cons: 正しく分割する が難しい • 商品モデルに「イートイン」専用 属性・振る舞いができたら？
60. アルプ 最近 悩み
61. マイクロサービスで予想される問題 (Alp) • 我々 モジュラモノリスで、まだマイクロサービスで ないが… • マイクロサービスにするとコアドメインをみんな触ることにならないか？ ◦ Scalebaseでいうと、カタログ・契約・請求 依存関係がなかなか切れない ◦ 契約に影響 ない機能開発が難しい • こ ような状況でマイクロサービス化 恩恵を受けられるか？ ◦ 何かうまい切り方 あるだろうか？ • ドメインコンテキストごと チームを組織して、認知負荷を下げたい ◦ ドメイン知識を個人で なくチームに貯めたい ◦ ど チームも契約について知る必要がある状況になりそう。これを回避するに ？
62. Scalebase モジュラモノリス https://speakerdeck.com/showmant/expressing-complex-domain-regions-and-boundaries-with-modular-monoliths
63. 意見交換
64. ありがとうございました