ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ #builderscon

Builderscon Tokyo 2019 の発表資料です。

Transcript

1. ビジネスの構造を扱うアーキテクチャと
   ユーザとの接点を扱うアーキテクチャ
   2019/08/30 Builderscon Tokyo 2019
   末並 晃 @a_suenami
   

   View Slide

2. 自己紹介
   ● 末並 晃 @a_suenami
   ● 生息している界隈: DDDとか、TDDとか、RDBとか
   ● お仕事で使ってる技術スタック: Rails, React, 最近 Java とかも
   少々
   ● 好きな RDBMS: PostgreSQL
   ● 好きな制約: チェック制約
   ● 好きな焼肉の部位: ハラミ
   ● 好きな（ｒｙ
   

   View Slide

3. インターネット上での立場
   

   View Slide

4. インターネット上での立場
   ひたすら焼肉をタカられるという
   エンターテイメントをインターネットに提供し
   ています。
   （焼肉を奢るとは言ってない）
   

   View Slide

5. インターネット上での立場
   とはいえ、すえなみチャンスは
   わりと真面目に募集しています。
   いろいろ教えてください。
   

   View Slide

6. 今日の話
   SoR と SoE
   

   View Slide

7. SoRとSoE
   ● SoR: System of Record
   ○ その名の通り、「記録」のためのシステム。
   ○ 入力の事前チェックの堅牢性、データ整合性の担保などが求
   められる。
   ● SoE: System of Engagement
   ○ 利用者との関係を構築するためのシステム。
   ○ 今どきの言葉を使うとよい UX を提供するためのシステム、と
   言い換えてもよい。
   

   View Slide

8. SoRとSoEの対比
   SoR SoE
   基本的な設計観点 データ整合性 柔軟性、性能
   データストア
   トランザクショナルな DB
   多くの場合、RDB
   スケーラビリティがある高速なデータ
   ストア
   ドキュメント指向DB、KVS、全文検索
   インデックスなど
   リリースサイクル
   SoEと比べると相対的に長い（諸説あ
   るかも）
   高速なリリースサイクルが求められる
   品質評価
   トラディショナルなソフトウェアテスティ
   ング手法を適用しやすい
   トラディショナルな手法に加え、ユー
   ザーテスト、ユーザーインタビュー、
   A/Bテストなど
   カナリアリリースも実トラフィックを利
   用したテストと捉えることができる
   データ整合性 トランザクション整合性が必須 結果整合性でよい要件も多い
   要するに？ 堅牢なMutation 柔軟なQuery
   設計を駆動する（しやすい）もの
   ドメインモデル、概念データモデル UI（ビジュアルデザイン、ユーザインタ
   ラクション）、キャッシュ
   

   View Slide

9. 本発表のモチベーション
   ● システム特性を SoR/SoE という分類をするのは直感的によいと
   思ったが、何故そう思ったかを各設計原則や設計パターンをベー
   スに言語化したくなった。
   ● 単なるバズワードとしてではなく、どのような設計観点があり、ど
   のような要求に対応し、どのような品質特性を満たすべきかを捉
   え直したい。
   ● 現在、扱っているアーキテクチャ設計についてご紹介をしたい。
   

   View Slide

10. 注意
    ● SoR/SoE は物理的に分けられている必要は必ずしもなく、言語やフ
    レームワークが持っているモジュール化や抽象化の仕組みで十分に分
    割できる。
    ● 物理的に分割するべきかどうかは microservices 界隈でさんざん議論
    されてるように、リリースサイクルや組織構造の問題であり、それが構
    造を与えるものか、接点を与えるものかとは別問題である。
    

    View Slide

11. 今日しゃべること
    ● モデルとは何か
    ● 各設計原則とSoR/SoE
    ● SoR/SoEの実践
    

    View Slide

12. モデルとは何か
    

    View Slide

13. https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm
    

    View Slide

14. モデルとは？
    https://ja.wikipedia.org/wiki/統一モデリング言語
    

    View Slide

15. モデルとは？
    

    View Slide

16. モデルとは？
    https://eng-etymo.com/archives/829#toc4
    

    View Slide

17. 解決したい問題領域から
    必要だと思われる情報を抽出して
    （逆に不要だと思われる情報を捨て）
    記号化、可視化したもの
    

    View Slide

18. 例: 地図
    ● 方角、距離、面積などのあらゆ
    る変数があるなか、それを正
    確に表現できているのは地球
    儀のみ
    ○ それでも完全に正確とは言
    えない
    ● メルカトル図法、正距方位図法
    など、目的に応じてさまざまな
    図法がある
    

    View Slide

19. 例: 連立方程式
    

    View Slide

20. モデルの世界と現実の世界
    

    View Slide

21. エリック・エヴァンスのドメイン駆動設計
    

    View Slide

22. モデル駆動設計
    

    View Slide

23. モデル駆動設計とは
    ● 分析モデルと設計モデルを分けず、単一のモデルで両方の営み
    を実現する手法をエリック・エヴァンスはモデル駆動設計と呼び、
    ユビキタス言語と並び DDD 本の中心的な主張となっている。
    ● そのためにオブジェクトモデルをモデルの中心として採用するべ
    きだと言っているが、他のモデリングパラダイムを否定しているわ
    けではない。
    

    View Slide

24. 第一部まとめ
    ● モデルとは解決したい問題のうち、必要な情報を抽出し、特徴づ
    け、記号化/可視化をしたものである。
    ● これ自体はソフトウェア開発に閉じたものではないし、実装の方
    法論というわけでもない。
    ● どのようなモデルが有効であるかは当然ながら対象とする問題領
    域に依存する。
    

    View Slide

25. 既存の設計手法とSoR/SoE
    

    View Slide

26. [再掲] 本発表のモチベーション
    ● システム特性を SoR/SoE という分類をするのは直感的によいと
    思ったが、何故そう思ったかを各設計原則や設計パターンをベー
    スに言語化したくなった。
    ● 単なるバズワードとしてではなく、どのような設計観点があり、ど
    のような要求に対応し、どのような品質特性を満たすべきかを捉
    え直したい。
    

    View Slide

27. 今回扱う事例: 2-sided platform
    ● モール型 E-Commerce サービスを考える
    ● システム利用者
    ○ 購買者ユーザ
    ○ 店舗ユーザ
    モール型
    EC プラットフォーム
    購入者 店舗
    

    View Slide

28. Clean Architecture
    

    View Slide

29. 単一責務の原則（SRP）
    ● SOLID 原則の一つで「クラスの変更理由はひとつであるべきであ
    る」とする設計原則。
    ● アンクル・ボブは Clean Architecture においてこの「変更理由」
    をさらに「アクター」と言い換えた。
    ● つまり、あるクラスやモジュールの変更は単一のアクターの変更
    要求によるものであるべきである。
    ● DBA や経営者もアクターの例として挙げられており、利用者だけ
    でなく、より広範な利害関係者を指している。
    

    View Slide

30. 単一責務の原則（SRP）
    ● CleanArchitecture ではクラスやモジュールの設計という観点で
    取り扱われているが、アプリケーション全体をある単一のアクター
    のためのものであると考えることも可能ではないか、というのを思
    考の出発点にする。
    

    View Slide

31. しかし、素朴に分割すると…
    

    View Slide

32. 分断されたモノリス！！
    購買者向け
    システム
    購入者 店舗
    店舗向け
    システム
    共通DB
    

    View Slide

33. 複数のアクターの要求がDBに直撃する
    購入者 出荷担当者
    いつ届くの？
    キャンセルしたい
    商品を間違ったので
    変更したい
    出荷しないと！
    在庫が残り少ないので仕
    入れ指示をしたい
    キャンセルされたので出
    荷を止めます
    「商品」「購入」などは一見ユビキタス言語かのように思われる
    が、多くの場合、次第に乖離し始める。
    共通DB
    ふ、ふええ…
    

    View Slide

34. もう一度、全アクターを見てみる
    経営者
    オペレーター
    マーケティング
    責任者
    倉庫・物流
    管理担当者
    商品購入者
    システム連携
    クライアント
    出荷
    担当者
    

    View Slide

35. アクターを分類してみる
    経営者
    オペレーター
    マーケティング
    責任者
    倉庫・物流
    管理担当者
    商品購入者
    システム連携
    クライアント
    出荷
    担当者
    事業者アクター 利用者アクター
    

    View Slide

36. 利用者アクターと事業者アクター
    ● 利用者アクターは自分がやりたいことややるべきことをできるだけ
    簡単にストレスなく完遂できることを望む。
    ● 事業者アクターは自分たちの事業を円滑に進めること、事業上の
    意思決定の支援をすること、蓄積されたデータや情報から新たな
    事業を創出すること等を望む。
    ● ドメインモデルと呼ばれるものは事業者アクターの視点のモデル
    であることが多いと感じる。
    ○ それがいいことかどうかは何とも言えない。
    

    View Slide

37. View Slide

38. 中央に事業者向けのモデルがあると考える
    購買者向け
    システム
    購入者 店舗
    店舗向け
    システム
    事業者の
    モデル
    ● DB を直接共有しないため、利用者アクターのユースケースに依
    存しない不変条件を維持することができる。
    ● システム全体が、事業者、購買者、店舗をそれぞれの要求元とす
    るサブシステムに分割された。
    

    View Slide

39. 勘のいい皆さんはもう気づきましたね？
    

    View Slide

40. SoR と SoE
    購買者向け
    システム
    購入者 店舗
    店舗向け
    システム
    事業者の
    モデル
    SoE SoR
    

    View Slide

41. ここまで考えると
    他の設計原則やパターンとの
    関連性も見えてきます
    

    View Slide

42. プレゼンテーションとドメインの分離（PDS）
    ● マーティン・ファウラーが提唱した、プレゼンテーションのロジック
    とドメインのロジックは分離するべきだとする設計原則。
    https://martinfowler.com/bliki/PresentationDomainSeparation.html
    

    View Slide

43. プレゼンテーションはモデルなのか
    

    View Slide

44. 再び DDD 本
    

    View Slide

45. 境界付けられたコンテキストとコンテキストマップ
    ● エリック・エヴァンスはあるモデルが有効な範囲を境界付けられた
    コンテキストと呼び、その間の関係はコンテキストマップで描くべ
    きだと主張した。
    

    View Slide

46. ドメインとプレゼンテーションの関係
    ● ドメインとプレゼンテーションの依存関係は、一般にプレゼンテー
    ションからドメインへの単方向依存である。
    ● DDD 本ではコンテキストマップのパターンがいくつか紹介されて
    いるが、ドメインとプレゼンテーションのこの関係は「顧客/供給
    者」パターンに最も近い。
    ● 「顧客」である利用者アクターのモデルから「供給者」たる事業者
    アクターのモデルに適切に振る舞いを移譲することによって、利
    用者アクターのモデルはプレゼンテーション優位の状態にでき
    る。
    ● プレゼンテーション優位なアプリケーションは適切なデータモデル
    （ドキュメントストア、KVSなど）を選定することによって入出力駆
    動での開発を進めやすくなる。
    

    View Slide

47. 再び Clean Architecture
    

    View Slide

48. ペリフェリックアンチパターン
    ● 中央にあるドメインを経由せずに、インフラストラクチャのコードを
    直接呼び出してしまうアンチパターン。
    ● パリ郊外にあるブルヴァール・ペリフェリック環状高速道路に由来
    する。
    ドメイン
    インフラストラクチャ
    

    View Slide

49. ペリフェリックアンチパターン
    ● アンクル・ボブは Clean Architecture においてこれをアンチパ
    ターンとしたが、プレゼンテーション優位な技術駆動アーキテク
    チャを選択する場合は、むしろ立派な実装パターンであると言え
    る。
    

    View Slide

50. CQRS
    https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf
    

    View Slide

51. CQRSとの関係
    

    View Slide

52. CQRSとの関係
    ● SoR/SoE という分類と Command と Query の非対称性に着目し
    た分離（=CQRS）は共通している部分が多く、得られる恩恵も近
    い。
    ● Command のモデル（≒ドメインモデル）から Query のモデルへ
    の変換の責務をどこが担うかという違いはあるような気がする？
    

    View Slide

53. Command/QueryとSoR/SoE
    SoR SoE
    Command
    いわゆる DDD というものが最
    も活躍する領域となる。
    入力値のみから可能なバリデーショ
    ンを行い、具体的な振る舞いをSoRに
    移譲する。
    現在の状態に依存するバリデーショ
    ンが必要な場合は、それもSoRへ移
    譲する。
    Query
    リソース指向、あるいはドメイン
    ロジック由来の集約を単位とす
    るデータ構造での参照のみで
    きる。
    RDBのマテリアライズドビューやサマ
    リーテーブル、ドキュメントストア、
    KVS、検索インデックスなどの具体的
    実装技術への依存を受け入れること
    によって性能、柔軟性、開発速度など
    を向上させることができる。
    

    View Slide

54. 第二部まとめ
    ● SoRは事業者アクターを要求元とするドメインモデルをもとにした
    アプリケーション、SoEは利用者アクターを要求元とするプレゼン
    テーションモデルをもとにしたアプリケーションと捉えることができ
    るのではないか。
    ● これは、Clean Architecture において主張された SRP の定義を
    発端に、PDS、境界付けられたコンテキストとコンテキストマップ、
    CQRS等、既存の設計原則や設計パターンで説明することができ
    る。
    

    View Slide

55. 第二部まとめ
    ● プレゼンテーションモデル優位の場合は設計を入出力に駆動さ
    せやすく、ドメインロジックを必要としないことが多い。
    ○ ペリフェリックパターンは、 Clean Architecture においてはア
    ンチパターンとして紹介されているが、具体的実装技術に駆
    動させやすいアプリケーションにおいてはむしろ立派な実装パ
    ターンと言えるのではないだろうか。
    ○ 実際、Greg Young の主張する CQRS パターンはそういう設
    計・実装パターンである。
    

    View Slide

56. SoR/SoEの実践
    

    View Slide

57. 簡易アーキテクチャ図
    ユーザ
    Cache
    Store
    CDN
    Pub/Sub Topic
    Master
    Database
    Subscribe
    Command
    SoE SoR
    

    View Slide

58. 設計観点
    ● バリデーション
    ● 整合性
    ● 採番
    ● 状態管理
    ● キャッシュ
    

    View Slide

59. バリデーション
    

    View Slide

60. [再掲] Command/QueryとSoR/SoE
    SoR SoE
    Command
    いわゆる DDD というものが最
    も活躍する領域となる。
    入力値のみから可能なバリデーショ
    ンを行い、具体的な振る舞いをSoRに
    移譲する。
    現在の状態に依存するバリデーショ
    ンが必要な場合は、それもSoRへ移
    譲する。
    Query
    リソース指向、あるいはドメイン
    ロジック由来の集約を単位とす
    るデータ構造での参照のみで
    きる。
    RDBのマテリアライズドビューやサマ
    リーテーブル、ドキュメントストア、
    KVS、検索インデックスなどの具体的
    実装技術への依存を受け入れること
    によって性能、柔軟性、開発速度など
    を向上させることができる。
    

    View Slide

61. バリデーション
    ● バリデーションと一般に呼ばれるものにも種類がある。
    ○ 入力値のチェック（長さや範囲、正規表現マッチなど）
    ○ その事業において必要な不変条件
    ○ Ruby の ActiveRecord 実装が（ｒｙ
    ● 構造的に自明だが、前者は後者の制約より同等かそれより厳しく
    なければならない。
    ● 現在状態に依存せず、値のみで可能な入力チェックは SoE で可
    能であり、そのほうが利用者に対してよい UX を提供できる可能
    性が高い。
    ○ JavaScript によるリアルタイムバリデーションなど
    

    View Slide

62. バリデーション
    

    View Slide

63. バリデーション
    ● バリデーションに関して重複を排除したいと考えた場合、基本的
    に誤った共通化の可能性を考えたほうがよい。
    ○ そういう意味では SoR と SoE が物理的に分割されているほう
    がよいケースもある。
    ○ サーバーサイドと同じバリデーションを JavaScript でもやるこ
    とに違和感を感じる人は多くないと思う。
    ● SoR でドメインモデルを構築している前提であれば、不変条件は
    独自型（ValueObject, etc）になり、コンパイラの恩恵も受けられ
    る。
    

    View Slide

64. 整合性
    

    View Slide

65. 以前、発表したやつ
    https://speakerdeck.com/a_suenami/soe-akitekutiya-number-kichijojipm
    

    View Slide

66. グローバルな整合性とユーザローカルな整合性
    ● SoR 的世界観ではシステム全体、あるいは連携システムも含め
    た全世界（大げさ）で不整合がないことが求められる。
    ● 一方、SoE 的世界観ではそれを利用する利用者一人ひとりが自
    分自身の世界を持っており、それがその人にとっては世界のすべ
    てである。
    

    View Slide

67. グローバルな整合性とユーザローカルな整合性
    ● SoR / SoE 間の疎結合性や耐障害性を高めるために、基本的に
    非同期、結果整合性でのアーキテクチャを検討するといいかもし
    れない。
    https://speakerdeck.com/a_suenami/soe-akitekutiya-number-kichijojipm?slide=16
    

    View Slide

68. [再掲] Command/QueryとSoR/SoE
    SoR SoE
    Command
    いわゆる DDD というものが最
    も活躍する領域となる。
    入力値のみから可能なバリデーショ
    ンを行い、具体的な振る舞いをSoRに
    移譲する。
    現在の状態に依存するバリデーショ
    ンが必要な場合は、それもSoRへ移
    譲する。
    Query
    リソース指向、あるいはドメイン
    ロジック由来の集約を単位とす
    るデータ構造での参照のみで
    きる。
    RDBのマテリアライズドビューやサマ
    リーテーブル、ドキュメントストア、
    KVS、検索インデックスなどの具体的
    実装技術への依存を受け入れること
    によって性能、柔軟性、開発速度など
    を向上させることができる。
    

    View Slide

69. 整合性
    ● リクエスト可能かどうかに応える（可能な場合は一定期間ロックを
    とる）エンドポイントを SoR から提供し、そこは同期的に結果を返
    すようにする。
    ● 決済処理における与信（オーソリ）と確定（キャプチャ）の関係。
    

    View Slide

70. 採番
    

    View Slide

71. 採番
    ● コマンドを結果整合性に寄せた場合、SoE はその完了を知ること
    ができなくなる。現実的には、ポーリングか Pub/Sub、あるいは
    何らかの画面レンダリングをフックに実データを問い合わせる形
    になるが、そのときのキーはリクエスト完了時には確定している
    必要がある。
    ● 実装パターンはいくつかある。
    ○ 採番のみを行うエンドポイントを SoR が提供する。
    ○ コマンドリクエスト完了時に同期的にキーを返す。
    ○ UUID など、SoE 側で採番可能な採番体系を選択する。
    

    View Slide

72. 採番
    ポーリングモデル
    

    View Slide

73. 採番
    Pub/Subモデル
    

    View Slide

74. 状態遷移・状態管理
    

    View Slide

75. 状態遷移・状態管理
    ● SoE のベースにあるのは特定の利用者アクターにとってのモデル
    なので、SoR が持つ事業全体の状態遷移のモデルとは基本的に
    異なる。
    ● SoR の状態遷移の一部だけが利用者にとっての関心領域であ
    り、SoE にその複雑さを持ち込まないようにする。
    

    View Slide

76. 状態遷移・状態管理
    購入者
    下書き
    レビュー待
    ち
    公開済み
    レビュー中
    商品特集記事状態遷移
    購入者の関心領域
    

    View Slide

77. 状態遷移・状態管理
    ● 実装としては、RDB のビュー、別のテーブルやデータストアに保
    持するといったいくつかのパターンがある。
    ● 物理的に分離する場合は、採番後の実データ問い合わせと同
    様、ポーリングや Pub/Sub 等で状態を最新に保つ工夫をする必
    要がある。
    

    View Slide

78. キャッシュ
    

    View Slide

79. キャッシュ
    ● キャッシュは基本的に SoE の関心時だと心得る。
    ● SoR 側の構造に引きずられないように、あくまで利用者の UX を
    ベースに考える。
    ○ ネイティブアプリや SPA (Single Page Application) のように
    サーバーサイド API とクライアントが分離されている場合はク
    ライアントがキャッシュしたい単位でエンドポイントや JSON 構
    造を設計する。
    ○ 難しい場合は BFF (Backend For Frontend) の導入も検討す
    る。
    

    View Slide

80. [再掲] 簡易アーキテクチャ図
    ユーザ
    Cache
    Store
    CDN
    Pub/Sub Topic
    Master
    Database
    Subscribe
    Command
    SoE SoR
    

    View Slide

81. キャッシュ
    キャッシュ指向のJSONオブジェクト設計
    

    View Slide

82. キャッシュ
    ● キャッシュとそのリフレッシュに対する戦略はいろいろ考えられ
    る。
    ○ キャッシュしない（毎回、SoR へ問い合わせる）
    ○ Pub/Sub によるリフレッシュ
    ○ Expire を待つ（一時的な不整合を許容する）
    ○ etc...
    

    View Slide

83. まとめ
    ● アプリケーションの要求元を事業者と利用者に分け、そのそれぞ
    れについてモデルを構築し、実装を考えると、それは一般に SoR
    / SoE の特性と呼ばれているものと一致する。
    ● バリデーション、整合性、採番、状態管理、キャッシュなどの具体
    的実装について、SoR / SoE のシステム間連携をどのように行う
    かの事例を紹介した。
    

    View Slide

84. まとめ
    

    View Slide

85. まだまだ試行錯誤している最中なので
    ぜひいろいろ議論したいです。
    よろしくお願いします。
    

    View Slide