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

by 集約のエンティティ

Slide 1

Slide 1 text

現場から学ぶシステム設計座談会 2021.10.27

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

各社紹介

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

座談会

Slide 25

Slide 25 text

前回テーマと振り返り

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

アルプ課題とトライ

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Product Backend 2. 注文＆決済記録失敗すると不整合が発生するケースもある ● 様々なところで失敗するケースがある整合性解消責務 ● プロダクトによって整合性定義が違うで、不整合解消責務プロダクト側におくべき ● しかし実現コストこちらもある程度高い ○ 全体設計やアプリケーションコード設計にどう影響させるかが悩み所 5. 決済 4.会計 7. 調理予約＋印刷 (非同期pub/sub) 9. 成功オフライン連携 APIs 1. 注文&決済 Platform Basic APIs 3. 仮注文 6. 注文確定 8. メール配信 7-1. 調理予約記録 7-2. 印刷決済代行(他社) 5-1. 決済失敗失敗前回勉強会でお悩み PF立ち上げ中で悩んだ整合性話注文整合性：分散トランザクションをした時どこかで失敗した時

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

アルプ最近悩み

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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