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