いかに開発効率と品質を高めるか: ドメイン駆動設計と組織パターンの視点から考える

©2023 Junichi Kato 1 / 98 いかに開発効率と品質を高めるか: ドメイン駆動設計と組織パターンの視点から考えるレバレジーズ株式会社様テックフェス2023春基調講演
2023/6/7 加藤潤一(@j5ik2o)

©2023 Junichi Kato 2 / 98 アジェンダ 1. 自己紹介 2.
発表の目的・想定対象者・大前提 3. 本日の主な参考資料 4. ドメイン駆動設計について思い出す 5. このスライドでの開発効率と品質の定義 6. テーマ1: 選択と集中のサブドメイン戦略 7. テーマ2: モデリングのツール: ドメインイベント 8. テーマ3: DDDのためのアーキテクチャパターン: CQRS/Event Sourcing 9. テーマ4:『組織パターン』のコンウェイの法則から考えるアーキテクチャと組織構造 10. 付録: Chatworkでの取り組み事例

©2023 Junichi Kato 3 / 98 自己紹介 Chatwork テックリード。ウェブ業界に転身後、ScalaやDDDを採用した開発に従事。現在は次期アーキテクチャの設計に携わる
執筆 WEB+DB PRESS Vol.126 - 21周年記念エッセイ今も読み続ける1冊の本レビューエリックエヴァンスのドメイン駆動設計 Akka実践バイブルドメイン駆動設計入門良いコード／悪いコードで学ぶ設計入門 WEB+DB PRESS Vol.132 - 特集1 オブジェクト指向神話からの脱却趣味はRustでアクターシステムを実装すること twitter: j5ik2o github: j5ik2o

©2023 Junichi Kato 4 / 98 発表の目的・想定対象者・大前提目的開発効率と品質を高めるために、ドメイン駆動設計と組織パターンをどう使うとよいのかを掘り下げる想定対象者
開発経験が3年以上あるエンジニア(そうじゃない人もこれを考える機会に🙏) 大前提この資料で提案されることは、私の経験から得た仮説に基づいています。その意味では発表者の主観が大いに混じっているのでご留意くださいこの資料で提案されることが、実際の現場で適用できるかは、個別の事象や状況を十分に踏まえたうえで判断して行ってください

©2023 Junichi Kato 5 / 98 本日の主な参考資料 DDDといえばこの本。ソフトウェア開発者が複雑なドメインを扱うアプリケーションを設計および構築するための書籍(以下、DDD本)
ソフトウェアを開発する上で「人間」とその「組織」に着目し、ソフトウェアを開発する際にどのような組織であるべきなのかを、実際の観察に基づいて書いている書籍

©2023 Junichi Kato 8 / 98 ドメイン駆動設計の3本柱コアドメインユビキタス言語モデル駆動設計
三本柱で言えば、モデル駆動設計やユビキタス言語を話す機会は多いです。今回はコアドメインから考えていき、モデル駆動設計の話は直接しませんが、モデリングという観点で最新の取り組みをお話したいと思います。

©2023 Junichi Kato 9 / 98 アプリケーションは何らかのドメインに属している釈迦に説法ですが・・・アプリケーションの存在意義は、そのアプリケーションが提供する「価値」によって定義されるこの「価値」とは、利害関係者の要求を満たす能力
であり、その要求は通常、特定の問題または課題として設定されるアプリケーションが問題や課題を解決する過程は、「問題ドメイン」と「解決ドメイン」の2つの領域に分けられるすべてのアプリケーションは、何らかの問題や課題を解決する目的を持つはずである。その問題や課題が具体的（例えば効率的なスケジューリング）であれ抽象的（例えばエンターテイメントやリラクゼーションの提供）であれ、全てのアプリケーションは特定のドメインにおける問題を解決することを目指している、と考えるのが自然である

©2023 Junichi Kato 10 / 98 ドメインとドメインモデル問題領域(問題ドメイン, DDDではドメイン) 問題の定義や価値について定める領域や範囲のこと
解決領域(解決ドメイン, DDDでは境界づけられたコンテキスト) ソフトウェアが解決する問題の領域や範囲のこと問題領域解決領域ドメインモデルドメインモデルの意味バージョン管理 Git コミットローカル時リポジトリへの変更登録 Subversion コミットセントラルリポジトリへの変更登録「ファイル」の定義は問題ドメインに依存するかもしれないが、「コミット」の定義は解決ドメインに依存するいずれにしても、ドメインモデルは、問題ドメインのモデルと解決ドメインのモデルの両方を含む。「深いモデル」は後者であることが多い出典: 「ドメイン駆動設計～ユーザー、モデル、エンジニアの新たな関係～」

©2023 Junichi Kato 13 / 98 このスライドでの開発効率と品質の定義開発効率(無駄なく開発を進めること) 不必要な作業を排除し、必要な機能のみを効率的に開発することを意味する品質(間違いなく開発を行うこと)
開発されたシステムがビジネス要件を正確に満たし、ユーザーの期待に応える能力を指す要は無駄なく・間違いなくのために、ドメイン駆動設計や組織パターンで何ができるのかという観点一般的な定義と異なるので注意

©2023 Junichi Kato 14 / 98 テーマ1: 選択と集中のサブドメイン戦略〜どのサブドメインから手を付けるべきか
〜

©2023 Junichi Kato 15 / 98 ドメインがサブドメインを持つことがある例えば、ECサイトの場合は、ドメインは「オンライン販売」となるが、一つの領域として扱うのには大きすぎる。「オンライン販売」というドメインは、以下の要素(サブドメイン)に分割できる(サブドメインは、ドメインの中で、特定の問題領域を表現する)
商品のレコメンド商品の購⼊フローレビューインベントリ管理顧客管理 ID ・認証・認可決済ログ管理通知なにから手をつけるか。何が重要なのだろうか

©2023 Junichi Kato 16 / 98 サブドメインの種類コアドメインをサポート一般的な問題を解決一般的な問題を解決
コアドメイン支援サブドメイン汎用サブドメインコアドメインは「重要なビジネス価値を提供」する。競争優位性を持つかどうかが決まる領域支援サブドメインはコアドメインを「サポート」する汎用サブドメインは「一般的な問題を解決」することで、コアドメインと支援サブドメインをサポートする ECサイト:コアドメイン「商品のレコメンド」「商品の購入フロー」 ECサイト:支援サブドメイン「レビュー」「インベントリ管理」「顧客管理」 ECサイト:汎用サブドメイン「ID・認証・認可」「決済」「ログ管理」「通知」

©2023 Junichi Kato 17 / 98 QCDSの観点から見たコアドメイン戦略コアドメインは、QCDSの観点から以下のような選択と集中を可能にするのではないか Quality（品質）コアドメインに注力することで、最も重要な機能やビジネスルールを適切にモデル化し、実装することができる
Cost（コスト）コアドメインにリソースや開発労力を集中させることにより、コスト効率を向上させることができる Delivery（納期）コアドメインにフォーカスすることで、開発プロセスを最適化し、納期遅延を最小限に抑えることができる Scope（範囲）コアドメインの明確な定義と設計により、プロジェクトのスコープを特定の領域に絞り込むことができる

©2023 Junichi Kato 18 / 98 コアドメインに対する疑問疑問1: コアドメイン以外のサブドメインは重要ではないのか？疑問2:
ユーザ側にとって重要な部分は必ずしもコアドメインに該当しない？

©2023 Junichi Kato 19 / 98 疑問1: コアドメイン以外のサブドメインは重要ではないのか？重要なのは、コアドメインと他のサブドメインの関係性や依存関係を理解し、適切にバランスを取ることコアドメインをサポート
一般的な問題を解決一般的な問題を解決コアドメイン支援サブドメイン汎用サブドメインコアドメインが競争上の優位性を提供する一方で、他のサブドメインはそのコアドメインを支える役割を果たす。コアドメインと他のサブドメインの組み合わせが、総合的なシステムの機能と価値を最大化する。したがって、コアドメインの重要性を認識しつつも、他のサブドメインも十分に重要であると考えるべき絶対的な優劣を付けるのではなく、ビジネスの要件や目標に応じて、コアドメインと他のサブドメインを適切に組み合わせてプロダクトを設計し、バランスを取ることが求められる

©2023 Junichi Kato 20 / 98 疑問2: ユーザ側にとって重要な部分は必ずしもコアドメインに該当しない？ユーザ側にとって重要な部分は必ずしもコアドメインに該当しないのは事実サブドメインは事業者としての視点で分類される(SoR的な価値観)
競争優位性以外に、成長性・顧客満足度・ブランド・CSRなどの観点もあるユーザの視点に立つと、コアドメインは違ってみえるかもしれない。ユーザは複数のドメインに横断的に関与することが多い。 ECサイトでは商品カタログ、ショッピングカート、決済システムなどと横断的にやり取りをすることとなるつまり、事業者の価値とユーザの価値は別。物差しが違うので別の指標が必要(SoE的な価値観) 例えばUXがその一つ。優れたUXは基礎なるドメインの複雑さに寄らず、ユーザにとってシームレスで直感的なインターフェイスを提供することができる非UXのユーザ価値としては、価格・製品の性能や品質・ブランドの評判や信頼性・製品のアクセシビリティが考えられる

©2023 Junichi Kato 21 / 98 テーマ1のまとめ「サブドメイン」の考え方をベースに、コアドメインの「商品の購入フロー」から手を付ける場合もあるし、他のサービスとの連携を想定して汎用サブドメインの「ID・認証・認可」から手を付ける場合もある。もしくは、サブドメインごとにチームがわかれていれば同時並行開発になるかもしれない。身も蓋もないが「サブドメイン」をどう選
ぶかは「戦略」によるさらに、競争優位性を担保する「コアドメイン」だけあればよいか、という問いに対しては、明らかに「Ｎｏ」と言える。コアドメインは他のサブドメインからのサポートがない限り機能しないし、プロダクトとしての本来の役目を果たせないからその意味から冒頭に挙げた「何から手を付けるか(優先順位付け)」の問いに対して、「サブドメイン」の考え方が完全な答えにはならないが、問題領域をより深く理解し戦略をサポートするツールとしては十分に有用であると考える

©2023 Junichi Kato 22 / 98 テーマ2: モデリングのツール: ドメインイベント〜
どのモデルから手を付けるべきか〜

©2023 Junichi Kato 26 / 98 FYI:「出来事」とは何か「出来事」はモノではなくコト「出来事」とは「起こった事態(事柄)」
つまり「成立した事態(事柄)」のこと 2020年コロナウィルスが流行した論理的に可能であれば成立していなくても「事態(事柄)」になる不成立でも言語にして意味が通れば論理空間の扱い 2021年関東が沈没する

©2023 Junichi Kato 27 / 98 イベントは過去形で表現されるイベントとは、ドメイン内で何か重要なことが起こったときに発生するもので、動詞の過去形で表現される商品が注文された(ProductPurchased) 商品が出荷された(ProductShipped)
イベントはビジネスの重要な振る舞いを表すため、それらに注目することでドメインの本質的な側面を理解しやすくなります

©2023 Junichi Kato 28 / 98 DDD本(2004年)にはドメインイベントは出てこない 2014年『Domain-Driven Design Reference:
Definitions and Pattern Summaries』にて初めて紹介された。

©2023 Junichi Kato 29 / 98 イベントを重視するモデリング手法は昔からある T字形ER 『T字形ERデータベース技法』(1998年) REAモデル
『Model-Driven Design Using Business Patterns』(2006年) 『ビジネスパターンによるモデル駆動設計』(2007年) 現在絶版 Event Storming 『Introducing EventStorming』(考案自体は2012年ごろ？現在執筆中) TM 『モデル作成技術TM入門』(2022年) これらの設計手法はすべてイベントを重要な要素として扱う。具体的には、システムやプロセスで発生する「何かが起こる」という事象や状態の変化を「イベント」と捉え、それらをモデル化することで、システムの振る舞いやビジネスのフローを理解・設計するのが特徴。

©2023 Junichi Kato 30 / 98 REAモデル Pavel Hruby著『ビジネスパターンによるモデル駆動設計』にて紹介された構造と振る舞いのモデルパターン。経済活動をResource,
Event, Agentのモデルを中心に記述する図の引用: REAとビジネスパターン入門(1)

©2023 Junichi Kato 31 / 98 FYI: REAに関する関連資料 “寿司屋”には「交換」「変換」の2パターンがある Scalaでモデル駆動を実現するために知っておきたいREAモデル
の捉え方部屋の予約はREAモデルだけでは説明できない『ビジネスパターンによるモデル駆動設計』から学ぶ実装課題点

©2023 Junichi Kato 32 / 98 モデル作成技術TM入門佐藤正美著『事業分析・データ設計のためにモデル作成技術TM入門』「T字形ER法」の進化形。構文論・意味論の観点から見直して、「関数」を中核に再体系かされた技術体系
第5章「関係」文法 1. R(Event, Resource): R(受注, 顧客)など 2. R(Event, Event): R(受注,請求)など 3. R(Resource, Resource): R(従業員, 部門)など 1:EtoR 2:EtoE 3:RtoR 受注顧客請求従業員部門

©2023 Junichi Kato 33 / 98 FYI: リソースとイベントの区別方法【簡易的な方法】見つけたモデルがリソース(モノ)かイベント(コト)かを迷った場合は、モデル名に「◦◦する」という動詞句を追加する
「配属する」は意味が通るので、配属はイベント「部署する」は意味不明なので、部署はリソース「分類する」は意味が通るが、分類はリソース【厳密な方法】「タイムスタンプが採取できること」もしくは「監査証跡が保管されていること」。どちらかを満たすものはイベントとなる「分類」はどちらもみたされないので、リソースとなる出典: 『T字形ERデータベース技法』

©2023 Junichi Kato 34 / 98 Event Storming ビジネスのプロセスをモデル化し知識を共有し、セッションの終わりには参加者全員がメンタルモデルを同期させ、ユビキタス言語の利用へ一歩踏み出すことができる
後ほど概要を説明します

©2023 Junichi Kato 36 / 98 イベント(コト)に注目すると全体の関係を整理しやすい(1/3) コトはヒトとモノとの関係として出現する入荷イベントには注文商品・注文者などが紐付くコトがモノ・ヒトと関連する
注⽂商品( モノ) ⼊荷( コト) 注⽂者( ヒト)

©2023 Junichi Kato 37 / 98 コトに注目すると全体の関係を整理しやすい(2/3) コトは時間軸に沿って明確な前後関係を持つ入荷イベントの前に注文イベントがある。逆転はないイベントの順序
⼊荷( コト) 注⽂( コト)

©2023 Junichi Kato 38 / 98 コトに注目すると全体の関係を整理しやすい(3/3) ヒトやモノから分析すると発散しがちコトを手がかりにすると効率的⼊荷
出荷⼊荷( コト) 出荷( コト) 商品( モノ) 担当者( ヒト)

©2023 Junichi Kato 39 / 98 「世界は事実の総体である」はモデリングにも当てはまるヴィトゲンシュタインの哲学から「世界は、事実の総体である。事物
の総体ではない。」世界が事物の総体であり、事実の総体ではないとしたら、「ここにリンゴがある」という事実すらも世界には含まれなくなってしまう世界を記述する際には、「事実」が中心的な要素となり、事物はその「事実」の一部として存在する。ソフトウェア設計のモデリングでは、動作や機能を理解するために、システム内の事物（エンティティなど）を単にリストアップするのではなく、それらがどのように相互作用し、どのような結果を生み出すかという「事実」に注目すべき。これは、システムの本質的な動作と機能を理解し、適切な設計と解決策を導き出すために非常に重要なアプローチである。

©2023 Junichi Kato 40 / 98 イベントに注目する効果 1. 【品質】明確なビジネス要件イベントはビジネスプロセスの重要な部分を表す。それらを理解し明確にすることで、ビジネス要件をより正確
に表現し、誤解を避けることができる 2. 【効率】共通の理解イベントに注目する技法は、ビジネスアナリスト、開発者、プロジェクトマネージャーなどのさまざまなステークホルダー間で共通の理解を生み出すのに役立つ 3. 【効率・品質】変更の容易さイベントに基づいたモデリングではイベントが独立して存在するため、ビジネスプロセスや要件が変更された場合でもその影響を最小限に抑えることができる以降は、イベントを利用したモデリング手法の、Event Stormingの概要を解説する

©2023 Junichi Kato 42 / 98 Event Storming Introducing EventStorming
- EventStorming EventStorming is a flexible workshop format for collaborative exploration of complex business domains. EventStormingは、複雑なビジネスドメインを共同で探索するための柔軟なワークショップ形式です。 DDD著者のEricさんも強力な手法であると説明している。考案者はAlberto Brandolini氏で2013年にはブログに最初の投稿がされています。海外での認知度は高く、Eric Evans氏のプレゼンテーションの中でも強力な手法であると言及されています。 [1] 1. 新しいモデリング手法: EventStorming (イベントストーミング) をはじめるための準備

©2023 Junichi Kato 43 / 98 ワークショップの形式が複数あるビッグピクチャーシステム価値・システム外部環境(コンテキスト)の観点プロセスモデリング
システム境界の観点(アクターとシステムの関係) システム設計レベルシステムの観点(システム内部の機能とデータ構造の関係) 詳しくは『Introducing Event Storming』を参照してください。今回は『Learning Domain-Driven Design』の簡便な方法を紹介します。

©2023 Junichi Kato 48 / 98 2.タイムラインをつくる時間の経過が左から右となることを前提に、イベントをビジネスドメインで発生する順序で並べる。同時に発生しそうなイベントは縦に並べるイベントはハッピーシナリオから始める。それができたら別のシナリオも追加してみる
並べたときに、イベントの抜け漏れに気付いた場合は適宜イベントを追加/修正する

©2023 Junichi Kato 55 / 98 9.集約を見つけるすべてのイベントとコマンドが分かれば、集約を発見できる集約の名前は問題ドメインから発見できるとは限りません。解決ドメインとして新たな言葉をつくる必要があるかも知れません。(バージョン管理の「コミット」のように)
FYI: 「集約の設計と実装」

©2023 Junichi Kato 57 / 98 リソースからは振る舞いの抽出が可能か通常、システム設計ではリソース（または「モノ」）に注目しがち例えば、顧客、商品、注文などのエンティティに焦点を当てるしかし、このアプローチでは、システムの振る舞いやビジネスルール、ビジネスプロセスなどを理解するのは困難な
場合があります注文注文の作成???( コマンド) 注文の挿入???( イベント) 注文の更新???( コマンド) 注文の更新???( イベント) 注文の削除???( コマンド) 注文の削除???( イベント) ドメイン知識が乏しいと、データを操作することにフォーカスしてしまいがち

©2023 Junichi Kato 58 / 98 イベントによって振る舞いを抽出し理解する一方、Event Stormingではこれらの「コト」を直接モデリングし、それらがどのように相互作用するかを理解します。これにより、システム全体の振る舞いを把握し、それがビジネスの要件とどのように一致するかをよりよく理解するこ
とができます。注文( 集約) 商品を注文する( コマンド) 商品が注文された( イベント) 注文数を訂正する( コマンド) 注文数が訂正された( イベント) 商品を取消する( コマンド) 商品が取り消された( イベント) コマンドが受理されるとイベントが発生する。集約のビジネスルールに合致しないコマンドは受理されない

©2023 Junichi Kato 60 / 98 テーマ3: DDDのためのアーキテクチャパターン: CQRS/Event Sourcing
〜Event Stormingをそのまま設計・実装する〜

©2023 Junichi Kato 63 / 98 クエリ要件を満たすことでリポジトリの実装が複雑になる取得した集約の集合を使ってドメインロジックを実行しないで、ドメインのデータを目的にリポジトリを使う例。様々なクエリ要件を満たすために、リポジトリの実装が複雑になる。
val employees: List[Employee] = employeeRepository.findByDeptIdsWithEmployeeNamePatterns(deptIds, employeeNamePatterns) // ドメインロジックは使わず、レスポンス用DTO に詰め込む

©2023 Junichi Kato 64 / 98 複数の集約から非正規型のDTOを得るのでN+1クエリが発生する以下はホテルの予約リストを取得する例。予約集約にはホテル名や顧客名は含まれていないため、ホテルIDと顧客IDから対応する集約を取得する必要があるリポジトリは正規化された集約を返すので、複数の集約から非正規型のDTOを得るためにN+1クエリが発生する。
val resavationDtos = reservationRepository.findByIds(ids) // SQL 発行 .map { reservation => val hotel = hotelRepository.findById(reservation.hotelId) // SQL 発行 val customer = customerRepository.findById(reservation.customerId) // SQL 発行 new ReservationDto(reservation, hotel, customer) }

©2023 Junichi Kato 65 / 98 集約から非正規型のDTOへの変換が非効率クライアントへ返す非正規型のDTOは、集約の一部のみの場合もある。そういうケースでデータ取得のためだけにリポジトリを使うケース。集約の一部を読み取り、他は捨てることになる
val customerNames = customerRepository.findByIds(ids).map{ customer => customer.name // 他のプロパティは捨てる }

©2023 Junichi Kato 66 / 98 クエリのためだけにドメインモデルを使うのは非効率クエリ要件を満たすことでリポジトリの実装が複雑になる複数の集約から非正規型のDTOを得るのでN+1クエリが発生する集約から非正規型のDTOへの変換が非効率
※ これらの問題が本当に問題なのか推測せずに計測したほうがいいし、仮に問題だとしても別の利点とトレードオフできるのではあればCQRSを使う必要はない val employees: List[Employee] = employeeRepository .findByDeptIdsWithEmployeeNamePatterns(deptIds, employeeNamePatterns) // ドメインロジックは使わず、レスポンス用DTO に詰め込む val resavationDtos = reservationRepository.findByIds(ids) // SQL 発行 .map { reservation => val hotel = hotelRepository.findById(reservation.hotelId) // SQL 発行 val customer = customerRepository.findById(reservation.customerId) // SQL 発行 new ReservationDto(reservation, hotel, customer) } val customerNames = customerRepository.findByIds(ids).map { customer => customer.name // 他のプロパティは捨てる }

©2023 Junichi Kato 69 / 98 CQRSとは Command and Query
Responsibility Segregation=コマンド・クエリ責務分離(2010年 Greg Young氏) CQRSはDDDのためのアーキテクチャパターンの一つ Separation ではなく、Segregationなので、C/Qをそれぞれ隔離することを意味する単なるモデルの分離ではない。モデルだけ分離して、隔離の境界がないものはCQRSとは言いがたい隔離をするので、Event Sourcingと組み合わせることが多い

©2023 Junichi Kato 70 / 98 なぜコマンドとクエリを分離するのかそもそもCとQで要件が異なるので、混ぜないで隔離するほうが望ましい特にクエリ要件が複雑なシステムでは効力を発揮するコマンド
クエリ一貫性/可用性一貫性重視。最新の書き込みが反映されるなければならない。トランザクション整合性(強い整合性)を使う可用性重視。つまりちょっと古いデータ見えてもよい。結果整合性(弱い整合性)を使うデータ形式正規化されたデータを保存する(集約単位≒概念単位) 非正規化されたデータ形式取得する(クライアント要求に合わせる) スケーラビリティ全体のリクエストに対して少ない比率。必ずしもスケーラビリティは重要ではない全体のかなりのリクエスト比率を占めるため、スケーラビリティが必要

©2023 Junichi Kato 71 / 98 CQRSでのシステム構成の例 Pros コマンドとクエリを別々にデプロイできる、耐障害性が高くなる
コマンドとクエリを別々に最適化できるため、スケーラビリティが高くなる Cons 分散システムとして、構成要素が多くなるネットワーク分断時に一貫性 or 可用性どちらを優先するか選択を迫られる

©2023 Junichi Kato 72 / 98 リードモデルの形式変換をしない場合の問題点 C/Qでデータベースまで分ける必要があるのでしょうか？これは明確に理由があります。例えば、入社日が EpocTime(Long値)としてDBに保存される場合、そのままではクエリのレスポンスに含めることができない。しかしクエリ側から値オブジェクトに依存ができないケースで問題があります。
エンコードされたドメインオブジェクト属性種別値 EmployeeId String “123456789” JoinedDate Long 1585039714572 クエリ側で値オブジェクトを使って値を形式変換する必要がある joinedDate.asFormattedString → "2020年03月24日 08:48" つまり、クエリがドメインに依存してしまうことになる。これを回避するためには、C/Qでデータベースを分けて、 RMUで事前に形式変換する必要がある

©2023 Junichi Kato 73 / 98 C/Qのモデル間の変換・同期の問題はイベントで解決 C/Qを隔離したら、どうやってデータをクエリサイドに同期させるかという問題がある。考案者のGregさんとしてはイベントを使うことを推奨している。 The
model that is best suited is the introduction of events, events are a well known integration pattern and offer the best mechanism for model synchronization. 最も適したモデルはイベントの導入であり、イベントはよく知られた統合パターンであり、モデルの同期化に最適なメカニズムを提供します。 Eventを中核においてアーキテクチャを考えたほうが、全体の設計のバランスがよくなります。そこでEvent Sourcing の話になります。拙作 CQRSはなぜEvent SourcingになってしまうのかになぜEvent Souringが必要になるか詳細に書いてあります。

©2023 Junichi Kato 74 / 98 Event Sourcing 過去に起きた出来事＝イベントイベントは不変で追記のみ
イベントを再生(リプレイ)すると最新状態が手に入る CounterInitialized(value=0) -> CounterAdded(value = 3) -> CounterSubtracted(value = 2) Counterの最新状態は1(この状態はコマンドのために利用される, クエリ側では別の仕組みを利用する)

©2023 Junichi Kato 75 / 98 Event Sourcingでのシステム構成の例 Pros CとQのモデル間の変換・同期の問題を解決できる
ドメインとしてはインピーダンスミスマッチを解消しなくてもよい(RMUがシンプルに解決する) C側でRDBを使う必要がなくなる。NoSQLと相性が良く、書き込みのスケールアウトも容易になる書き込みは追記のみになるため、スケーラビリティを確保しやすい(レコードを一切ロックしない) イベントを使って他のマイクロサービスとの連携が容易になる監査や分析に利用できる Cons 長大なイベントから状態をリプレイする際に時間がかかるすべてのイベントをストレージに保存する必要がある

©2023 Junichi Kato 76 / 98 性能劣化はある程度カバーできる Consの性能劣化は、ライブラリやフレームワークによる仕組みで解消できるになっている長大なイベントから状態をリプレイする際に時間がかかるあらかじめN件ごとにスナップショットを保存しておく
リプレイ時に最新のスナップショット＋差分イベントだけを読み込むことでパフォーマンス劣化を最小化できるすべてのイベントをストレージに保存する必要がある最新のスナップショットより古いイベントは削除することが可能イベントを削除すると、イベントからリードモデルを再構築することができなくなる

©2023 Junichi Kato 77 / 98 コマンドプロセッサの実装イメージ (1)〜(3)は以下のように抽象化可能。この実装では、スナップショットが利用されているとはいえ、ユースケースの実行ごとにリプレイが行われるところが難点。Akka/Scalaではアクターとしてキャシュすることでジャーナルやスナップショットと完全に同期した状態を維持
できる。つまり、(1)から(3)が初回実行以外は不要となる。 class AddCartItemUseCase(cartPersistenceService: CartPersistenceService) { def execute(cartId: CartId, cartVersion: Version, itemId: ItemId, num: ItemNum): Unit = { // (1) スナップショット取得 val snapshot = cartPersistenceService.getLatestSnapshotById(cartId) // (2) スナップショット以後のイベント取得 val events = cartPersistenceService.getEventsByIdAndSeqNr(cartId, snapshot.seqNr) // (3) 最新状態に再生( リプレイ) val cart = Cart.from(snapshot, events) // (4) 集約の振る舞いを実行 val (newCart, itemAdded) = cart.addItem(itemId, num) // (5) 新しい集約状態とイベントを永続化 cartPersistenceService.store(newCart, itemAdded, cartVersion) // DynamoDB などに書き込まれる } } val cart = cartPersistenceService.replay(cartId, cartVersion)

©2023 Junichi Kato 78 / 98 具体的な実装はどうしたらよいのか時間の関係ですべてを話せないので、以下のリンクを参考にしてください Akka/Scala CQRS
Event Sourcing Proto.Actor/Golang プログラミング言語非依存 AWS データベースブログの記事「Amazon DynamoDBによる CQRSイベントストアの構築」を勝手に読み解く

©2023 Junichi Kato 80 / 98 明確な境界がないCQRSに似た妥協パターン(有用な場合もある) コマンド側ではドメインロジックの起動に専念する。クエリ側では原則的にリポジトリを含めてドメインを利用しない。ただし前述したフォーマット変換などにVOを使うことを許容する C/Qの境界線を明確に引くことができないので、モジュールの依存関係の制御が難しくなりがちだが、分散システム
にいきなり移行できない場合は選択肢に入る

©2023 Junichi Kato 81 / 98 テーマ3のまとめ CQRSはDDDのためのアーキテクチャパターンの一つ C/Qごとの要件に合わせて独立して最適化できる利点がある。一方でそれなりの手間がかかるほとんどのスタートアップで、最初から分散システムを構築するのは難しい
CQRSの基本原理を抑えつつ、明確な境界がないCQRSに似た妥協パターンも有用な場合もある

©2023 Junichi Kato 84 / 98 DDDと関係がありそうなパターン一覧『組織パターン』と『エリックエヴァンスのドメイン駆動設計』は、「システムと組織の複雑さを管理し、価値のあるソフトウェアソリューションを効果的に実現する」という、共通の目標を持つ、と考えられるサブドメインや境界づけられたコンテキストに関連するパターン
コンウェイの法則信頼で結ばれた共同体一つのタスクに一つのチームスキルに応じたサブシステム実践的モデラに関係するパターンアーキテクトも実装する今回は「コンウェイの法則」について議論します。

©2023 Junichi Kato 85 / 98 メルヴィン・コンウェイの「コンウェイの法則」「システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を生み出す」という法則。組織のコミュニケーションを阻害するような、システム構造であってはならない (※
「システムを設計する組織」を念頭におかないと認識がずれやすいので注意)。組織のコミュニケーション構造地域A 地域B 組織A 組織B 組織C 密疎疎実際にできあがるシステム構造組織A のコンポーネント組織B のコンポーネント組織C のコンポーネント密疎疎左側の組織構造に倣ったアーキテクチャが作られる地域(コミュニケーションの構造)が同じ場合はコミュニケーションが密になり、異なる場合は疎になっている。よくも悪くも組織の構造をシステムに反映されてしまうということ

©2023 Junichi Kato 86 / 98 逆コンウェイ作戦引用: 『エンジニアリング組織論への招待 ~不確実性に
向き合う思考と組織のリファクタリング』コンウェイの法則は、悪い組織構造が、悪いアーキテクチャを生み出すというような文脈です。これは取引コストの高い組織が、取引コストの高いアーキテクチャを生み出してしまい、「技術的負債」現象を引き起こしてしまうということを意味しています。一方で、コンウェイの法則を経営活動にとってポジティブに利用しようとする考えが近年では生まれてきました。この関係性を逆手にとって、積極的な組織設計やコミュニケーション設計をビジネス戦略に基づいて行うことで、アーキテクチャ自身をより良いものに変えていこうとする考え方です。コンウェイの法則自体は悪い組織構造が悪いアーキテクチャを生み出すという考え方。逆コンウェイではこのネガティブな理由を逆手にとり、組織設計やコミュニケーション設計を基にアーキテクチャをよりよいものとして設計するという考え方

©2023 Junichi Kato 87 / 98 『組織パターン』での「コンウェイの法則」問題サマリ組織の構成要素（たとえば、チームや部署、課など）がプロダクトの本質的な構成要素を反映していない場合、あるいは組織間の関係がプロダクトの構成要素間の関係を反映していない場合には、そのプロジェクトは困ったことになるだろう。
システムのアーキテクチャにより、組織のコミュニケーションパスが形作られる。事実上の組織構造が正式な組織構造を形作るのだ。そして、正式な組織構造が今度はアーキテクチャを作る。早期に行われるアーキテクチャの制定は、推測でしかなく、不安定だ。しかし、このアーキテクチャは、ある一定のリズムに支配されていて、そのリズムがコアビジネスコンピテンシーとなる領域を反映している。そして、ビジネスに関わるこのレベルの関心は、アーキテクチャ構造全体に対する幅広い関心と結びつくよりも、組織の構造と密接に結び付くのだ。解決サマリそれゆえ: 組織をプロダクトのアーキテクチャと対比できるようにしよう。パターン言語におけるこの時点では、アーキテクチャが組織を駆動するべきであり、組織に応じてアーキテクチャを定めるべきではない。ソフトウェアの設計とその必要性が組織構造を決定すべきである考え方。メルヴィンとは逆向きの視点になっている。組織構造はソフトウェアのアーキテクチャによって最適化されるべきで、その逆（組織構造がソフトウェアのアーキテクチャを決定する）は避けるべきだという主張

©2023 Junichi Kato 88 / 98 「アーキテクチャが組織を駆動するべき」とは？例えば、一つの大きなソフトウェアプロジェクトがあり、そのアーキテクチャが複数の独立したサービスまたはコンポーネントによって構成されると想定する。これらの独立したサービスやコンポーネントそれぞれに対応する形で組織を分割し、各チームがそのコンポーネントに専念するようにするべきだと提案している。
これにより各チームが特定のサービスやコンポーネントに専念でき、それによって生じる課題に集中的に取り組むことができる。(DDDのサブドメインや境界づけられたコンテキストと通じる考え方) ビジネス要求を満たすアーキテクチャが最適であるなら、組織構造はそのアーキテクチャをサポートする形に調整するべきだということ。これはコンウェイの法則の「組織構造がソフトウェアのアーキテクチャを形成する」現象を逆に利用し、ソフトウェアのアーキテクチャが最適な組織構造を作るというもの

©2023 Junichi Kato 89 / 98 組織とアーキテクチャには戦略が必要メルヴィンは組織を基にアーキテクチャ、コプリエンはアーキテクチャを基に組織を考える必要性と説いている。どちらも事実である。しかし、組織かアーキテクチャかという極端な二項対立的思考に陥らないように「戦略」を意識することが重要
「組織は戦略に従う」と、経営史学者アルフレッド・チャンドラーは提言しました。後に、経営学者イゴール・アンゾフが「戦略は組織に従う」と考えました。どちらかが正しいのではありません。どちらも事実であり、組織は戦略と深い関係があります。さらにもう1つ、メルヴィン・コンウェイの言葉を足してみましょう。「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」。これは、コンウェイの法則として知られている法則です。チャンドラー、アンゾフ、コンウェイの考えをつなぎ合わせると、組織は戦略に、戦略は組織に従います。そして、システムは組織を映す鏡となります。引用: 『エンジニアのためのマネジメント入門』組織は戦略に従い戦略は組織に従うシステムは戦略に従う組織はシステムに従う組織戦略システム

©2023 Junichi Kato 90 / 98 テーマ4のまとめ組織からアーキテクチャ、アーキテクチャから組織への相互作用を意識することで、組織とアーキテクチャの両方を改善していくことができる組織
vs アーキテクチャの二項対立的思考ではなく、一貫した「戦略」に基づいて組織もアーキテクチャも設計していく必要がある

©2023 Junichi Kato 93 / 98 アーキテクチャに対応する組織もスケールできるように変化させていく Scrum@Scaleは単一のスクラムチームをそのままスケールすることにより拡張する。単一のスクラムチームの最適な構成人数が4,
5人程度であると言われているように、複数のスクラムチームの最適な構成数は4つか5つをまずは上限と考えられる。これがScrum of Scrumチーム。このScrum of Scrumチームは、仮想的なスクラムチームとして振る舞う。つまり、Scrum of Scrumチームはスプリントの終わりに統合されたインクリメントに対して責任を持つことになる。また、仮想的なスクラムチームとして、各スクラムイベントを執り行う。Scaled Daily Scrum (SDS)、Scaled Retrospectiveなど。

©2023 Junichi Kato 95 / 98 FYI: 次期アーキテクチャ向け開発関連の資料 2020-07-16 リアクティブ・アーキテクチャ基礎講座
2020-11-20 リアクティブは難しいが役に立つ 2021-05-26 リアクティブシステムと次世代基盤について 2021-06-07 ChatworkにおけるScrum@Scale導入への挑戦 2022-03-23 Chatworkのリライトプロジェクトをやっている 2022-03-24 Scrum@Scaleによる組織構造の変遷

©2023 Junichi Kato 96 / 98 まとめ本資料では、ドメイン駆動設計と組織パターンを切り口に、無駄と間違いを避けるの観点について説明した。サブドメイン戦略：「サブドメイン」の考え方が完全な答えにはならないが、問題領域をより深く理解し戦略をサポートするツールとしては十分に有用であると考える
モデリングのツールとしてのドメインイベント：ドメインイベントを用いたモデリング手法を採用し、ビジネスの重要な振る舞いをフォーカスできる。また、具体的な手法の一つとしてEvent Stormingの概要を紹介した CQRS/Event Sourcing：CQRSはDDDのためのアーキテクチャパターンの一つ。C/Qごとの要件に合わせて独立して最適化できる利点がある。一方でそれなりの手間がかかる。CQRSの基本原理を抑えつつ、明確な境界がない CQRSに似た妥協パターンも視野にコンウェイの法則：相互作用があるが、組織 vs アーキテクチャの二項対立的思考ではなく、一貫した「戦略」に基づいて組織もアーキテクチャも設計していく必要がある

©2023 Junichi Kato 97 / 98 著作権表示とライセンス著作権者は加藤潤一です。このライセンスはクリエイティブ・コモンズ
表示 - 改変禁止 4.0 国際ライセンスの下に提供されています。改変しない限り自由に配布・利用が可能です

いかに開発効率と品質を高めるか: ドメイン駆動設計と組織パターンの視点から考える

いかに開発効率と品質を高めるか: ドメイン駆動設計と組織パターンの視点から考える

More Decks by かとじゅん

Other Decks in Design

Featured

Transcript