TRACERYプロダクトマネージャーの haru です。
「設計」とは、単にシステムを構築するための作業ではなく、長期的に価値を生み出すための重要なプロセスです。
ソフトウェアが事業において長期的に価値を生み出すためには、ソフトウェア開発者が「設計にこだわる」*1ことが必要だと私は思います。
「設計にこだわる」とは、ソフトウェアから価値を生み出すためには設計はこうあるべきだという理想を持ち、それを実現し、やり続けることです。
本記事のテーマであるドメイン駆動設計（DDD: Domain-Driven Design）でいえば、その理想とは「事業戦略とソフトウェアの実装を結びつける」*2ことであり、開発者が事業や業務担当者と「同じ言葉」を共有し、現実の業務をソフトウェアにモデリングする（実装する）という活動を持続することです。
その対極にあるのが「動けば良い」という考え方です。自分が担当する機能の実装が早く終わり、最終テストをパスすれば、その後のことはどうでも良いというスタンスです。
「動けば良い」という考え方は「個人的・短期的」な価値を目指し、「設計にこだわる」という考え方は「全体的・長期的」な価値を目指しています。
ドメイン駆動設計は「全体的・長期的」な価値の実現を目指した設計手法です。
ドメイン駆動設計の書籍で最近界隈で話題となっているドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法（以下、本書）を拝読しました。
本記事では、前半で各章の内容を紹介し、後半では私が感じた特徴についてお伝えします。
本書の内容
ドメイン駆動設計はシステム開発全体*3をスコープとした設計手法です。
そのため、本書の内容をV字モデル*4に照らし合わせて紹介します。
第Ⅰ部 設計の基本方針
第Ⅰ部は、「戦略的設計」を説明しています。戦略的設計では、事業全体を複数の業務に分類し、それぞれの開発の方向性、注力すべきポイントを決定します*5。
- 1章 事業活動を分析する
- 2章 業務知識を発見する
- 3章 事業活動の複雑さに立ち向かう
- 開発する対象を区切られた文脈で分割し、一貫した「同じ言葉」を使うスコープを定める
- 4章 区切られた文脈*11どうしの連係
- 区切られた文脈どうしが連係する方法、パターン、文脈の地図（コンテキストマップ）の説明
戦略的設計は、V字モデルにおける企画や要件定義（業務要件定義、システム要件定義）に対応しています。
第Ⅱ部 実装方法の選択
第Ⅱ部は「戦術的設計」について説明しています。戦略的設計で分割された各文脈に基づいて、具体的なソフトウェアアーキテクチャや実装方針の選択肢について説明されています。
- 5章 単純な業務ロジックを実装する
- トランザクションスクリプトやアクティブレコードを採用するケースについての説明
- 6章 複雑な業務ロジックに立ち向かう
- ドメインモデルの説明（値オブジェクト、エンティティ、集約、業務サービスでの表現）
- 7章 時間軸でモデルを作る
- イベントソーシング*12、イベント履歴式ドメインモデルの説明
- 8章 技術方式
- レイヤードアーキテクチャ、ポートとアダプター、コマンド・クエリ責任分離（CQRS:Command-Query Responsibility Segregation）の説明
- 9章 通信
- 区切られた文脈の間を連携するための通信方法。モデル変換装置、共用サービス等
戦術的設計は、V字モデルにおける基本設計、詳細設計、プログラミングに対応します。
第Ⅲ部 ドメイン駆動設計の実践
第Ⅲ部では、開発中の設計判断や業務領域の変化に応じて設計をどのように変更していくかについて説明しています。第Ⅱ部までの理論的な説明から実践的な内容へと移行しています。
- 10章 設計の経験則
- 実装方法とテスト方針の選択方法
- 11章 設計を進化させる
- 業務領域の成長や変化に伴う設計方針の変更
- 12章 イベントストーミング
- イベントストーミングという業務プロセスのモデリング手法の説明
- 13章 現実世界のドメイン駆動設計
- 既存システムにドメイン駆動設計を取り入れるための考え方や進め方
V字モデルでは、企画〜基本設計までに対応します。
第Ⅳ部 他の方法論や設計技法との関係
第Ⅳ部は、分散システムやデータ分析システムなど、時代に応じた設計手法とドメイン駆動設計の関係について説明しています。
- 14章 マイクロサービス
- マイクロサービスとドメイン駆動設計（主に業務領域や区切られた文脈）
- 15章 イベント駆動型アーキテクチャ
- イベント駆動型アーキテクチャによって、区切られた文脈のインターフェースを設計する考え方
- 16章 データメッシュ
- データメッシュ構築におけるCQRSと区切られた文脈どうしの連携
V字モデルでは、システム要件定義に該当します。
このようにV字モデルと対応させると、ドメイン駆動設計はシステム開発全体をスコープに含んでいることが理解できるでしょう。
本書の特徴
ここからは、本書を読んで感じた特徴についてお話ししたいと思います。
ドメイン駆動設計の現在地を把握できる
ドメイン駆動設計をテーマにした勉強会に参加する中で、ドメイン駆動設計の原典であるエリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう（通称エヴァンス本）には掲載されていない設計手法がテーマになることがあります。たとえば、イベントソーシング、CQRS、ポートとアダプター(クリーンアーキテクチャ*13含む)、マイクロサービスなどです。勉強会では時間が限られているので仕方のないことなのですが、ドメイン駆動設計との関係性が見えにくいと感じることがありました*14。
本書ではこれらの設計手法を図解で解説した後、ドメイン駆動設計との関係性を明確にしています。そのため、これらの設計手法や考え方がどのようにドメイン駆動設計と結びついているのかを理解することができます。これにより、現在のドメイン駆動設計の全体像や、コミュニティで注目されているテーマをしっかりと把握できるでしょう。
読みやすく、理解しやすい
エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かうは、比較的難解であるとよく言われています*15。本書を読んで驚いたのはその読みやすさです。特に私が感銘を受けたのは「同じ言葉」という訳語です。今までのドメイン駆動設計の書籍や訳書では、ユビキタス言語*16と訳されていたものを、本書では思い切って「同じ言葉」と訳しています。
ドメイン駆動開発に取り組む現場で「みんなで同じ言葉を使いましょう」というのと「みんなでユビキタス言語を使いましょう」では、どちらが理解されやすく、話が早いかと言えば、明らかに前者でしょう。訳者は、日本の開発現場でのわかりやすさを考慮して、この訳語を選んだのだと思います。本書は、日本におけるドメイン駆動設計の推進に大きく貢献する一冊となるでしょう。
著者の失敗体験から学ぶことができる
本書は、著者のドメイン駆動設計への取り組みから得た豊富な経験を元に書かれています。それだけに、失敗経験を元にした内容も多く書かれています。ドメイン駆動設計も万能ではありません。本書内でも述べられているように適さない場面もありますし*17、文脈を区切りすぎる（「分割した大きな泥団子」と表現されている）など設計を誤ると悲惨なことになります。そのような失敗をしないためのバランス感覚を本書からは学ぶことができます。
特に、付録Aの「ドメイン駆動設計の実践:事例研究」は必見です。マーケットノバス社（仮名）というスタートアップでドメイン駆動設計を用いて経験したあらゆる失敗と学び、そして成果が語られています。
ドメイン駆動設計による実装の具体的な内容をさらに学びたい方には
上述の「本書の構成」で示したように、本書はドメイン駆動設計の戦略的設計から戦術的設計の実装の基本方針（ソフトウェアアーキテクチャ）を決めるところまでの内容が中心で、具体的な実装コードについては説明が少なめです*18。
ドメイン駆動設計の実装について具体的に学びたい方には、訳者の増田亨さんが執筆された現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法をおすすめします。この書籍では、ドメイン駆動設計の考え方が、実装を中心に解説されています。プログラムコードから入る方がイメージしやすい方には、特におすすめです。
また、この書籍については、別のブログで記事を書いていますので、よろしければご参照ください。
最後に
開発者には「設計へのこだわり」が必要だと記事の冒頭で述べましたが、それをやり続けるのは容易ではありません。
ソフトウェア開発者は、システムやソフトウェアという自身の専門領域に視野を集中させ、事業や業務から距離を置く方が楽だからです。しかし、そのような姿勢は、長期的には開発生産性の低下を招き、最終的には事業成長スピードの低下につながります。
これを克服し、事業に貢献するためには、開発者自身が事業や業務に関心を持ち、それを日々の仕事に反映させる必要があります。そのためにドメイン駆動設計は最適な解決策となるでしょう。
ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法は、設計にこだわり、事業に貢献しようとする開発者にぜひ読んでほしい一冊です。
*1:株式会社アクティアの高崎健太郎さんのスライド「設計に「こだわる」とは / Sekkei-ni-kodawaru - Speaker Deck」に共感し、「設計にこだわる」の言葉をいただきました。
*2:本記事で紹介する書籍のサブタイトル
*3:広義のシステム開発を指す。システム開発におけるシステムとは何か - TRACERY Lab.（トレラボ）を参照のこと。
*4:V字モデルについては、V字モデルの基本構造をWhy,What,How,Make,Testの視点で理解する - TRACERY Lab.（トレラボ）を参照のこと
*5:ひとことでいうと「分割して統治せよ」ということ
*6:競合する他社との差別化要因となる業務領域。コアドメインと訳されることもある
*7:業務は複雑なことは多いが、事業の競争優位を生み出さない業務領域。そのため他社の製品やサービスを使うことが多い。
*8:業務ロジックが単純で、事業の競争優位を生み出さない業務領域
*9:ユビキタス言語のこと。システム開発において、開発チームとドメインエキスパートが共通の言語を使ってコミュニケーションするための概念。
*10:人が現実世界や抽象的な概念を理解し、解釈するために頭の中に構築する認知的な枠組みや概念図のこと
*11:境界づけられたコンテキストとも訳される。特定の意味やルールが一貫して適用される領域、範囲のこと
*12:Event Sourcing：アプリケーションの状態をデータベースに保存する際に、状態そのものではなく、状態の変化（イベント）を順番に記録していくアーキテクチャパターン。各イベントが発生した順序で保存され、そのイベントの履歴を再生することで、いつでも任意の時点のシステムの状態を再構築できる。これにより、変更履歴が完全に保持されるため、デバッグや監査、将来の変更に対する柔軟性が高まる。
*13:書籍:Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)
*14:イベントソーシング、CQRS、ポートとアダプターは、書籍実践ドメイン駆動設計で紹介されている
*15:日本語訳に関わらず、原著でも同じようです
*16:システム開発において、開発チームとドメインエキスパートが共通の言語を使ってコミュニケーションするための概念。この言語は、ドメイン駆動設計（DDD）の中核的な要素であり、システムが扱うビジネスドメインの専門用語や概念を含む。ユビキタス言語の目的は、技術的な専門知識とビジネス的な知識を橋渡しし、複雑なドメインの理解を深め、システムの品質を向上させること
*17:「一般的な業務領域」や「補完的な業務領域」は事業の差別化につながらないので適さない。
*18:原著のタイトルが「Learning Domain-Driven Desgin: Aligning Software Architecture and Business Strategy」なので、ソフトウェアアーキテクチャ設計までが中心なのは納得
