はじめに
先日モノタロウさんのイベントに参加してとても素晴らしい内容だったのでパネルディスカッションに参加していた増田さんが翻訳した「ドメイン駆動設計をはじめよう」を読んでみました📚
目次
第Ⅰ部 設計の基本方針
1章 事業活動を分析する
- 1.1 事業領域（ビジネスドメイン）とは何か
- 1.2 業務領域（サブドメイン）とは何か
- 1.3 事業分析の具体例
- 1.4 業務エキスパート
- 1.5 まとめ
- 1.6 演習問題
2章 業務知識を発見する
- 2.1 事業の課題
- 2.2 知識の発見
- 2.3 意図の伝達
- 2.4 「同じ言葉」とは何か？
- 2.5 業務で使う言葉
- 2.6 事業活動のモデル
- 2.7 まとめ
- 2.8 演習問題
3章 事業活動の複雑さに立ち向かう
- 3.1 異なるモデルの混在
- 3.2 区切られた文脈とは何か
- 3.3 区切られた文脈と業務領域の関係
- 3.4 文脈の境界
- 3.5 現実世界の区切られた文脈
- 3.6 まとめ
- 3.7 演習問題
4章 区切られた文脈どうしの連係
- 4.1 緊密な協力
- 4.2 利用者と供給者の関係
- 4.3 互いに独立
- 4.4 文脈の地図
- 4.5 まとめ
- 4.6 演習問題
第Ⅱ部 実装方法の選択
5章 単純な業務ロジックを実装する
- 5.1 トランザクションスクリプト
- 5.2 アクティブレコード
- 5.3 現実的に考える
- 5.4 まとめ
- 5.5 演習問題
6章 複雑な業務ロジックに立ち向かう
- 6.1 歴史
- 6.2 ドメインモデル
- 6.3 まとめ
- 6.4 演習問題
7章 時間軸でモデルを作る
- 7.1 イベントソーシング
- 7.2 イベント履歴式ドメインモデル
- 7.3 よくある質問
- 7.4 まとめ
- 7.5 演習問題
8章 技術方式
- 8.1 業務ロジックと技術方式
- 8.2 レイヤードアーキテクチャ
- 8.3 ポートとアダプター
- 8.4 コマンド・クエリ責任分離
- 8.5 スコープ
- 8.6 まとめ
- 8.7 演習問題
9章 通信
- 9.1 モデルの変換
- 9.2 集約どうしの連係
- 9.3 まとめ
- 9.4 演習問題
第Ⅲ部 ドメイン駆動設計の実践
10章 設計の経験則
- 10.1 経験則
- 10.2 区切られた文脈
- 10.3 業務ロジックの実装方法
- 10.4 技術方式の選択
- 10.5 テストの基本方針
- 10.6 実装方法の判定
- 10.7 まとめ
- 10.8 演習問題
11章 設計を進化させる
- 11.1 事業活動の変化
- 11.2 設計の基本方針を再検討する
- 11.3 業務ロジックの実装方法を見直す
- 11.4 組織の変更
- 11.5 業務知識
- 11.6 システムの成長
- 11.7 まとめ
- 11.8 演習問題
12章 イベントストーミング
- 12.1 イベントストーミングとは何か
- 12.2 誰がイベントストーミングに参加するべきか
- 12.3 イベントストーミングに必要なもの
- 12.4 イベントストーミングのプロセス
- 12.5 いろいろなやり方
- 12.6 イベントストーミングをいつ使うか
- 12.7 ファシリテーションのコツ
- 12.8 まとめ
- 12.9 演習問題
13章 現実世界のドメイン駆動設計
- 13.1 戦略的な分析
- 13.2 設計改善の基本方針
- 13.3 実践的なドメイン駆動設計
- 13.4 ドメイン駆動設計を売り込む
- 13.5 まとめ
- 13.6 演習問題
第Ⅳ部 他の方法論や設計技法との関係
14章 マイクロサービス
- 14.1 サービスとは何か？
- 14.2 マイクロサービスとは何か？
- 14.3 ドメイン駆動設計とマイクロサービスの境界
- 14.4 公開インターフェースを小さくする
- 14.5 まとめ
- 14.6 演習問題
15章 イベント駆動型アーキテクチャ
- 15.1 イベント駆動型アーキテクチャとは？
- 15.2 イベント
- 15.3 イベント駆動型の連係を設計する
- 15.4 まとめ
- 15.5 演習問題
16章 データメッシュ
- 16.1 分析系データモデルと業務系データモデル
- 16.2 分析系データの管理基盤
- 16.3 データメッシュ
- 16.4 まとめ
- 16.5 演習問題
結びの言葉
- 課題
- 解決方針
- 実現手段
- さらに学ぶために
- 最後に
付録A ドメイン駆動設計の実践：事例研究
- A.1 五つの区切られた文脈
- A.2 ふりかえり
- A.3 まとめ
各章についての感想
全体を通して読んだ感想としては自分が今まで読んだことのあるドメイン駆動設計関連の本の中で一番わかりやすいと思いました。
特に大胆に従来の訳語と違う訳語を当てることで内容がすんなり入ってくるようになりました。
またドメイン駆動設計のなかに出てくる戦略的設計の部分が朧げな認識だったのですがこの本では具体的な事例が出てきたので腑に落ちました。
従来の訳語との対応表
| 項目 | 言語 | 翻訳 |
|---|---|---|
| domain | ドメイン | 事業活動または事業領域 |
| subdomain | サブドメイン | 業務領域 |
| domain logic | ドメインロジック | 業務ロジック |
| domain event | ドメインイベント | 業務イベント |
| Ubiquitous Language | ユビキタス言語 | 同じ言葉 |
| Bounded Context | 境界づけられた文脈 | 区切られた文脈 |
| Context Map | コンテキストマップ | 文脈の地図 |
| Shared Kernel | 共有カーネル | モデルの共有 |
| Anticorruption Layer | 腐敗防止層 | モデル変換層 |
| Separate Way | 別々の道 | 互いに独立 |
各章で気になったところをメモしていきます。
1章 事業活動を分析する
事業活動を理解するためのドメイン駆動設計の考え方とやり方が説明されていました。
事業活動を以下の３つの業務領域に分類して説明されています。
- 中核の業務領域
- 一般の業務領域
- 補完的な業務領域
それぞれがどんな内容か具体例で示されていたので理解しやすかったです。
三つのカテゴリーの比較も参考になりました。
| カテゴリー | 競争優位 | 複雑さ | 変化 | 実装 | 課題の特徴 |
|---|---|---|---|---|---|
| 中核 | ⭕️ | 複雑 | 多い | 社内 | 複雑で興味深い |
| 一般 | ❌ | 複雑 | 少ない | 製品購入や外部サービス利用 | 既存の解決策がある |
| 補完 | ❌ | 単純 | 少ない | 社内または外部委託 | 明確 |
また業務エキスパートについて記載もありました。
2章 業務知識を発見する
同じ言葉（ユビキタス言語）について書かれていました。
- お互いの意図を効率的に伝えたいなら、変換するのではなく、同じ言葉を使わなければいけません。
- 同じ言葉は業務で使う言葉で技術用語を含めません。
- 同義語は意図が違うのであれば、それぞれの用語を特定の文脈ごとに使い分ける。
モデルについても言及がありました。
モデルとは
モデルは、現実のモノや出来事を簡略化した表現です。特定の側面を意図的に
強調して、一方で、それ以外の側面を意図的に除外します。
モデルは用途を限定した抽象化です。
- レベッカ・ワーフスブラック
地図の例もとてもわかりやすかったです。
今でこそモデルの意味を理解できるようになりましたが、昔は本当に理解できなかったので早くこの説明に出会いたかったです🤪
「あらゆるモデルはまちがっている。しかし役に立つモデルはある」。
3章 事業活動の複雑さに立ち向かう
区切られた文脈について書かれています。
- 文脈の境界を設計するのはソフトウェア技術者
- 業務領域は「発見」、区切られた文脈は「設計」
- 一つの業務領域に一つのモデルという固定観念は持たない！
4章 区切られた文脈どうしの連携
区切られた文脈どうしの連携方式として6種類紹介されています。
- 良きパートナー
- モデルの共有
- 従属
- モデル変換装置
- 共用サービス
- 互いに独立
システム全体の関係を表すものとして文脈の地図（コンテキストマップ）も紹介されています。
5章 単純な業務ロジックを実装する
ここでは業務ロジックの実装方法として以下の２つが紹介されていました。
- トランザクションスクリプト
- アクティブレコード(ORM フレームワークの Active Record ではなくて設計パターン)
この２つは以下の場合に向いているそうです。
- 補完的な業務領域
- 一般的な業務領域用の外部サービスとの連携
- 区切られた文脈同士を連携する時のモデルの変換
6章 複雑な業務ロジックに立ち向かう
複雑な業務ロジックの実装方法としてドメインモデルが説明されています。
お馴染みの 値オブジェクト、エンティティ、集約、業務イベント、業務サービスなどが紹介されています。
業務ロジックをドメインモデルで実装するのは、業務ロジックが複雑な業務領域だけです。
ですから、ドメインモデルを選択するのは、ソフトウェアの心臓部である中核の業務領域だと
考えておけばよいでしょう。
7章 時間軸でモデルを作る
イベント履歴式ドメインモデルについて解説されています。
イベント履歴式ドメインモデルとは？
ドメインモデルと違って、イベントソーシングを使って集約の状態を管理します。
集約の状態を永続化するのではなく、集約の状態が変化したことを業務イベントで表現し、業務イベントの履歴を「真実を語る唯一の情報源」(the source of truth)として永続化します。
この章では「利点」と「欠点」が書かれていて採用時の参考になりそうでした。
8章 技術方式
以下の３つのアプリケーションアーキテクチャが紹介されています。
- レイヤードアーキテクチャ
- ポートアダプター
- コマンド・クエリ責任分離（CQRS:Command-Query Responsibility Segregation）
9章 通信
コンポーネント同士の連携方法が紹介されています。
- 区切られた文脈どうしの通信方法
- 集約の設計原則に起因する連携方法の制約に対処する方法
- 複数の区切られた文脈にまたがる業務プロセスの実現方法
10章 設計の経験則
具体的にどういう場合にどうすればいいか？が説明されています。
この章は以下の図が素晴らしいです🥳
実装方法とテスト方針の判定方法
11章 設計を進化させる
事業活動の変化によって「中核」、「補完」、「一般」のカテゴリーが変化する具体例が書かれています。
業務領域のカテゴリーを変更する理由
また、業務ロジックの実装変更もそれぞれの場合で紹介されています。
- 中核の業務領域はロジックが入り組んでいるだけではなく、たびたび変化します。そしてモデル作りがずっと続きます。
人生において唯一普遍なことは変化である。
12章 イベントストーミング
今回読んでみて一番刺さったのはこの章かもしれません。
イベントストーミングとは、業務プロセスのモデルを迅速に作ることを目的に、
関係者が集まって、ブレインストーミングスタイルで進めるローテクな手法です。
ある意味で、イベントストーミングは、業務知識を共有するための戦術的なツールと言えるでしょう。
イベントソーシングと字面が似てますがこちらはモデリングの手法です。
この章ではイベントソーシングの具体的なやり方が書かれています。
イベントソーシングの目的としては以下のものが挙げられます
- 同じ言葉の構築
- 業務プロセスのモデル化
- 新しい業務要件の探求
- 失われた業務知識の修復
- 既存の業務プロセスの改善方法を探る
- 新しいチームメンバーへのガイダンス
ドメイン駆動設計で開発をするためにイベントストーミングをしなくても関係者全員で
共通のモデルを共有するだけでもかなり意味がありそうだなと思いました。
イベントストーミングを現在のチームで実際に試してみようと思います。
モノタロウさんで実際に行われたイベントストーミングの様子は以下の記事で見れます。
13章 現実世界のドメイン駆動設計
この章は二番目に刺さりました。
既存のサービスにドメイン駆動設計を導入しようとしている人にはとても参考になる章だと思います。
章の最初に理想的な状況でドメイン駆動設計に取り組めるとしたら、それは宝くじに当たったようなものです。と書かれており、ドメイン駆動設計の有識者がそろっていて、新規の開発案件に携わることができる場合にドメイン駆動設計が効果を発揮すると言うのは誤解だそうです。
またドメイン駆動設計が大きな効果をもたらすのは、すでに稼働しているソフトウェアに取り組んだ場合です。とも書かれています。
というのも実は現在大きな泥団子も対象になるということです。
ドメイン駆動設計は全ての技法を使わないといけないということはなく部分的に取り入れるだけでも効果を発揮するということです。
実際、稼働中の大きな泥団子にドメイン駆動設計の色々な技法を取り入れることはできないと思います。
この章では大きな泥団子に対してドメイン駆動設計の考え方や、やり方を徐々に取り入れていくための戦略的なやり方が書かれています。
ここに関してはかなり共感していて、現在自分が所属しているチームでもレガシーなコードをベースを触ることがあるのですが、値オブジェクトを取り入れるだけでもコードの責務や見通しがスッキリし、テストも書きやすくなったという恩恵を得ています。
戦略的な分析などおこなってからストラングラーパターンを使って徐々に改善していく方法が紹介されています。
14章 マイクロサービス
マイクロサービスについて書かれています。
中でもマイクロサービスと区切られた文脈が同じものか？という自分もモヤモヤしていた部分の説明がありスッキリしました😁
すべての マイクロサービス は 区切られた文脈 だけど
すべての 区切られた文脈 は 必ずしも マイクロサービス ではないということです。
この章には図がいくつかあり、どれも示唆に富むものでした。
マクロサービスとして切り出す時にはこの章を再度熟読する必要がありそうです。
15章 イベント駆動型アーキテクチャ
イベント駆動型アーキテクチャについて書かれています。
冒頭に以下が書いてあり興味がそそられました。
イベント駆動型アーキテクチャを安易に取り入れると、「モジュラーモノリス」を「分散した大きな泥団子」に変えてしまうかもしれません。
また、イベント駆動型アーキテクチャとイベントソーシングの違いが以下のように書かれていました。
イベントソーシングは、状態の変化を一連のイベントとして補足する方法。
イベント駆動型アーキテクチャ：サービス間の通信方法
イベントソーシング：サービス内部の実装方法
そのほかにもイベントカテゴリーの具体例が書いてありイメージがしやすかったです。
イベント駆動型は最悪のケースを想定して設計しないといけないというのもよくわかりました。
16章 データメッシュ
分析データを管理する仕組みとしてデータメッシュが解説されています。
分析系モデルは事実テーブルと特性テーブルでデータを構造化します。
分析系モデルとしては以下の２つが紹介されています。
- 星型スキーマ
- 雪の結晶型スキーマ
分析系データの管理基盤としては以下の２つが紹介されています。
- データウェアハウス
- データレイク
上記２つの限界を乗り越えるために考案されたのがデータメッシュということです。
データメッシュの基本の考え方
- データを業務の視点で分割する
- データをプロダクトと考える
- 自立性を高める
- エコシステムを構築する
この章は正直なところあまり事前知識が無くてしっくり来てません・・・😅
結びの言葉
ドメイン駆動設計の本質として次の言葉が書かれています。
課題の合意なしに解決方針の話をしても無意味である。
解決方針の合意なしに実現手段の話をしても無意味である。
- エフラット・ゴールドラット・アシュラグ
やはり課題の理解が大事！
- 私たちが取り組んでいる事業活動は何か
- 事業目標は何か
- 事業目標を達成するための戦略は何か
思考を停止した、形だけのドメイン駆動設計をやらないようにする！
なぜそうするのかを理解してドメイン駆動設計に取り組む！
同じ言葉を使って開発できているかいつも気に掛ける！
疑わしいときはイベントストーミングをする！
さいごに
最初から最後までためになる話満載で今ドメイン駆動設計をはじめるなら間違いなくこの本をお勧めします😆
今年読んだいくつかの本の内容とリンクする部分があり色々しっくりきました。
具体的には TRANSFORMED の プロダクトモデル の実装において ドメイン駆動設計 の手法が
ハマりそうだと思ったことと、ドメイン駆動設計を行うに当たって チームトポロジー の組織作りが効果を発揮しそうだと思いました。さらに組織運営において エンジニアリング組織への招待 の内容がなじみそうだなと思いました。
今年色々と学んだ内容を来年には実際に形にしていければと思います😉
まずはイベントストーミングからやってみる💪
Discussion