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

現場から学ぶシステム設計:座談会 / 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. 現場から学ぶ
    システム設計 座談会
    2021.10.27

    View Slide

  2. タイムテーブル
    時間 内容
    19:00 - 19:05 オープニング
    19:05 - 19:20 各社紹介 事業、プロダクト 紹介
    19:20 - 19:40 座談会 前半戦 3ヶ月前 悩みと振り返り
    19:40 - 20:20 座談会 後半戦 最近 悩み
    20:20 - 20:40 意見交換

    View Slide

  3. 今日 テーマ
    現場で悩んだ設計について相談・議論を通じて理解を深めよう

    View Slide

  4. 今日 きっかけ
    ● アルプで 社内で定期的に設計について相談する会を実施
    ● 今年7月にLegalForceさんShowcase Gigさんと一緒に議論する会を実施
    ● そして今日
    ○ 前回 学びを現場に持ち帰って、そ 後 アップデートを発表する場
    ○ また、新しい設計 悩みについて議論する場

    View Slide

  5. 本日 メンバー
    田坂さん
    鈴木さん
    daiさん
    宮腰さん
    田宮さん 荒木さん
    集約
    エンティティ
    竹尾
    男爵
    増田さん
    @masuda220
    @yuuuutsk
    @suzushin54
    @dskst9 @dnskimox
    @showmant_
    @pictiny
    @A_Tree
    @miyakosis

    View Slide

  6. 各社紹介

    View Slide

  7. View Slide

  8. View Slide

  9. View Slide

  10. View Slide

  11. View Slide

  12. View Slide

  13. View Slide

  14. Mission
    全て 契約リスクを
    制御可能にする。
    ※契約リスク と
    契約に含まれる「不利な条件」や「法
    令違反」を指す

    View Slide

  15. 契約書 作成・審査
    法務担当者 業務時間
    平均4割を占める
    LegalForce Conference 2020に参加した
    法務担当者に対する調査より (n=883)

    View Slide

  16. 契約 締結前
    契約書レビュー 品質向上と
    効率化を実現する
    AI契約審査プラットフォーム
    契約 締結後
    締結済み 契約書を自動で
    データベース化する
    クラウド契約書管理システム
    企業向けに契約リスクを制御する2つ 製品を提供しています

    View Slide

  17. 私たち 経済活動 、さまざまな契約で成り立っ
    ています。それ 同時に契約リスクが潜んでいる
    ということ。
    LegalForce 、最新 テクノロジーと法務 知見
    を組み合わせて契約リスクを可視化し、制御可能
    な状態へ導きます。
    あるべき権利が適切に守られ、不測 事態が防が
    れるために。そして、より豊かで信頼に満ちた経済
    社会を目指します。

    View Slide

  18. @j5ik2o氏を迎えオンラインで毎
    週ドメインモデリング勉強会を
    行っています
    ※画像 イメージです
    ※写真に@j5ik2o氏 含
    まれていません
    ※写っている 全員弊
    社エンジニアです

    View Slide

  19. View Slide

  20. View Slide

  21. これから 「あたりまえ」を生み出すプラットフォーム
    店舗 新しい提供態と顧客体験をつくりだし、
    店舗における省人化や顧客満足度向上を同時に実現しています。

    View Slide

  22. View Slide

  23. 各種POS機器
    店舗オペレーション
    店舗内注文管理デバイス
    注文伝票出力プリンタ
    注文表示サイネージ
    オフライン
    オンライン
    オフラインとオンラインが融合する
    それ インターネット 開発で 経験すること できない課題があります。

    View Slide

  24. 座談会

    View Slide

  25. 前回 テーマと振り返り

    View Slide

  26. 値オブジェクト 導入
    LegalForce 田宮

    View Slide

  27. 肥大化するユースケース
    とりあえずやったこと
    ● Mixinを使った手続き処理 共通化
    共通処理をまとめること できたけど、今度 テストが肥大化。
    些細な改修でも大幅なテスト改修が必要になっていた。。。
    散ら った手続き型 コードを責務毎にいい感じにまとめられないかなぁ
    、とここら辺で真剣に考え始める

    View Slide

  28. いや、待てよ 🤔
    利用しているHanami(弊社が利用しているフレームワーク)がドメイ
    ン層を提供してくれてるよ 🤔🤔🤔
    ※Hanami クリーンアーキテクチャを実践しているフレームワークです。依存関係を意
    識した開発ができます。DIP!

    View Slide

  29. 問題を掘り下げてみた
    永続化層と関連があるオブジェクトをとにかく神聖化
    永続化層(技術的なレイヤ)とドメインオブジェクトを切り離した設計ができてなかった
    技術的なレイヤを切り離した設計に踏み出す。
    →値オブジェクト 導入
    → 継続的なリファクタリングで豊かなモデルを実装

    View Slide

  30. 値オブジェクトを実装する時 ルール
    ● 外部I/Oが発生しない操作だよ
    ● 依存なし 設計にして (ドメイン・オブジェクト同士 🙆)
    ● ユースケースを元に概念整理を行った上で実装しよう
    ○ 計測、説明、判定など 振る舞い 実装
    ● 不変性、比較、等々教科書に載ってる制約

    View Slide

  31. 値オブジェクトを導入して良かったこと
    ● 実装が楽しくなった
    ● Mixinを使った共通化より粒度が細かい で、再利用価値が増した
    ● よりセキュアなアプリケーションが実装できるようになった
    ● 名前空間を意識した設計(context境界)を実践し、他チームと コンフリクトを減ら
    せると期待

    View Slide

  32. アルプ 課題とトライ

    View Slide

  33. Scalebase Connect for Salesforce (SFA) 開発
    課題
    ● 技術セットが大きく異なる
    ○ Apex、LWC、、、
    ● Salesforce Application 開発者 採用が難しい
    ● コアシステム ドメインを流用した実装があり、負債化している
    ○ 請求から見積を作っている
    トライ
    ● 社内 Webエンジニアがコンバートしやすい設計へリファクタし内製化へ
    ● サブシステム用 ドメインを切っていく
    ○ 見積にフィットするドメインモデルをコアシステムに作る (予定)

    View Slide

  34. PF立上げ 中で悩んだ整合性 話
    Showcase Gig Inc.
    PF開発チーム TL 田坂

    View Slide

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

    View Slide

  36. 注文を例に整合性について考える
    ● 注文 会計や決済 事実と一対一 関係
    ● どれかが欠けた状態 (不整合)だと店舗で 注文オペレーションが出来ない で 不整合を解消する必要 がある
    PF立ち上げ 中で悩んだ整合性 話
    注文 会計 決済
    完了
    メール
    注文 中 処理 内訳 (※テイクアウト ケース)

    View Slide

  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事業をしていると遭遇しやすい
    どんな時分散トランザクションになる?

    View Slide

  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立ち上げ 中で悩んだ整合性 話
    注文 整合性:分散トランザクションをした時
    どこかで失敗した時

    View Slide

  39. そもそもだけど、整
    合性ってほんとに
    大事な ?
    増田さん
    他に大事なこともっ
    とあるんじゃない?
    私たち
    確かに。。
    不整合を防ぐ方法に固執
    していた。。
    PF立ち上げ 中で悩んだ整合性 話
    そもそも
    失敗すると不整合が発生するケースもある
    ● 様々なところで失敗するケースがある
    整合性解消 責務
    ● プロダクトによって整合性 定義が違う で、不整
    合 解消責務 プロダクト側に おくべき
    ● しかし実現コスト こちらもある程度高い
    ○ 全体設計やアプリケーションコード 設計
    にどう影響させるかが悩み所
    前回 勉強会で
    お悩み
    どこかで失敗した時

    View Slide

  40. 結論
    一連 処理において不整合が起きた時
    機能的に使えていれ 良く、解消すべき不整合があっ
    たときに解消できれ 問題ない!
    大事なこと
    ● 不整合に気づけること
    ● 不整合を解消できること
    ○ 手動や必要に応じて自動
    実践したこと👍
    ● 不整合に気づけること
    ○ 失敗時 アラート
    ● 不整合が起きる ケース 洗い出し
    ○ どんな時にど ように
    不整合を解消すべきかを整理
    ● 不整合を解消できること
    ○ PF側で不整合解消 API 提供
    ■ 各種取り消しAPI
    ■ 一部自動解消job
    ○ プロダクト側で 手動解消機能 実装
    PF立ち上げ 中で悩んだ整合性 話
    そもそも質問を受けて
    そもそもだけど、整
    合性ってほんとに
    大事な ?
    増田さん
    他に大事なこともっ
    とあるんじゃない?
    私たち
    確かに。。
    不整合を防ぐ方法に固執
    していた。。

    View Slide

  41. 最近 悩み

    View Slide

  42. サーバ間
    トランザクション制御
    LegalForce 宮腰

    View Slide

  43. マイクロサービス(風) 構成
    web service
    application logic
    (server)
    AI
    レビュー
    テキスト
    検索
    ・・・
    request
    分散トランザクション 実装していないため、
    サーバ間でデータ不整合が起きるケースがある
    → 次 ページ以降で「ユーザ作成」を例に説明
    R&D team 製品開発 team

    View Slide

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

    View Slide

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

    View Slide

  46. ユーザ作成(ロールバックに失敗)
    ● ✓ ☓ユーザ情報 DB登録→削除に失敗
    ● ✓✓Auth0 (認証サービス) ユーザ作成→削除に成功
    ● ☓ Intercom (ユーザーサポートチャットサービス) ユーザ作成
    ● Welcome メール送信
    ロールバック処理で失敗した場合に不整合が発生してしまう・・・

    View Slide

  47. トランザクション制御できない操作を
    どう保証するか
    ● 基本的に ログにエラー情報を出力して手動でリカバリ対応する?
    ○ 顧客が増えると対応工数がそれに比例する
    ○ でも直前 ユーザー作成に成功している で、削除に失敗するケー
    ス 少なそうな でこれでいいかな・・・
    ● ロールバック処理 成功するまで無限に繰り返す?
    ○ ちょっと強引すぎるかも
    ○ 1日1回 定期リカバリバッチを作っておき、リカバリ対象データを登
    録しておく

    View Slide

  48. 複数 境界づけられたコンテキストにおける
    共通ロジック 扱いについて
    Showcase Gig Inc.
    プロダクト開発チーム TL 鈴木

    View Slide

  49. Showcase Gig - 最近 悩み
    複数 境界づけられたコンテキストがあるとき
    共有したいモデルやユースケース
    ど ように扱うべきか

    View Slide

  50. 用語 確認
    境界づけられたコンテキスト
    ● ドメイン 問題を技術的ソリューションで解決するも
    ● 巨大なモデルを構築しないためにユビキタス言語 境界に従
    い分割

    View Slide

  51. そ 悩み おかしい で ないか?
    ・・・と思う人もいるかもしれません
    モデルを定義・適用する境界を明示的に示した結果
    作られるも が境界づけられたコンテキストなんだから、
    共有したいユースケースやモデルなんてある方がおかしい で 🤔

    View Slide

  52. 境界づけられたコンテキスト 例
    実際に 特定 ドメイン
    問題解決に複数システムが
    関わることがある
    『実践ドメイン駆動設計』 第2章 ドメイン、サブドメイン、境界づけられたコンテキスト より

    View Slide

  53. 私たち システム (プロダクトバックエンド)
    ※実際 システムから表現を
    変更・簡略化しています
    ビジネス ルールが
    変わる単位で分割
    ドメイン
    モバイルオーダー

    View Slide

  54. 私たち システム (プロダクトバックエンド)
    ※実際 システムから表現を
    変更・簡略化しています

    View Slide

  55. 課題 再確認
    複数 境界づけられたコンテキストがあるとき
    共有したいモデルやユースケース
    ど ように扱うべきか

    View Slide

  56. 課題 具体例
    注文モデル
    コンテキスト
    ごとに異なる
    注文商品モデル 共通
    ドメインモデルや
    それを利用する処理が重複しがち

    View Slide

  57. モジュラモノリスとして実装

    View Slide

  58. 単純にコードを流用すると
    異なるコンテキスト ユースケースを呼び出してしまうことに
    モジュール化と 🤔

    View Slide

  59. 考えられるアプローチ
    1. 1つ システムとして扱う
    ○ イートイン、テイクアウトを統合
    ■ pros: ロジック 重複を排除できる
    ■ cons: DDDと 真逆 アプローチ😕
    2. モジュール分割 観点を変える
    ○ サブドメイン[注文] と [商品]
    ○ テイクアウトやイートイン モジュールから呼び出す
    ■ pros: モデル 重複を排除できる
    ■ cons: 正しく分割する が難しい
    ● 商品モデルに「イートイン」専用 属性・振る舞いができたら?

    View Slide

  60. アルプ 最近 悩み

    View Slide

  61. マイクロサービスで予想される問題 (Alp)
    ● 我々 モジュラモノリスで、まだマイクロサービスで ないが…
    ● マイクロサービスにするとコアドメインをみんな触ることにならないか?
    ○ Scalebaseでいうと、カタログ・契約・請求 依存関係がなかなか切れない
    ○ 契約に影響 ない機能開発が難しい
    ● こ ような状況でマイクロサービス化 恩恵を受けられるか?
    ○ 何かうまい切り方 あるだろうか?
    ● ドメインコンテキストごと チームを組織して、認知負荷を下げたい
    ○ ドメイン知識を個人で なくチームに貯めたい
    ○ ど チームも契約について知る必要がある状況になりそう。これを回避するに ?

    View Slide

  62. Scalebase モジュラモノリス
    https://speakerdeck.com/showmant/expressing-complex-domain-regions-and-boundaries-with-modular-monoliths

    View Slide

  63. 意見交換

    View Slide

  64. ありがとうございました

    View Slide