参考書籍一覧（Amazon アソシエイトリンク）

グルー（glue）とは接着剤のことで、特にコンポーネントの組み合わせでコードを組み立てる接着剤の役割をする言語をグルー言語と言ったりする。

DDDは以下の要素をくっつけ、パッケージングしたものである。

要求分析
アーキテクチャパターン
マイクロサービス

マイクロサービス

エリック・エヴァンスのドメイン駆動設計の原書が出版されたのは2003/8/22である。このとき、マイクロサービスという言葉はなかった。

実践ドメイン駆動設計の原書が出版されたのは2013/2/16である。このときも、マイクロサービスという言葉はなかった。

マイクロサービスという言葉はマーチン・ファウラーとジェームス・ルイスによって、2014/3/25に生み出された。

エヴァンス本において戦略的設計として複数のシステムに分けたり連携させることについて言及していたために、DDDはシステム分割に関する技術的問題をも取り込むことになってしまった。

私は、マイクロサービスはマイクロサービスの話題としてDDDから切り離して考えるべきだと思っている。サーガやイベントソーシングはドメインには関係のない技術的な問題である（要求としてイベントの記録があるなら別だが）。そういった問題を解決する能力はアーキテクトに求められるものであり、ドメインの分析やモデリングに必要な能力とは別の能力である。また、マイクロサービスはDDDの前提ではない。モノリシックなシステムでもDDDは可能である。

DDDの初学者が苦しむ原因の一つは、DDDといいながらマイクロサービスの話をするブログエントリやツイートが多いせいではないか。ただでさえ群盲象を評す状態のDDD界隈で、「象の牙」を「象」と呼ぶ人間がいるのである。混乱しないわけがない。

※なお、私も群盲の一人かもしれないので、眉に唾をつけて注意すること。

アーキテクチャパターン

ServiceやEntity、ValueObjectなど、ユビキタス言語をコードとして表現するために必要なパターン、FactoryやRepositoryなどのそれらを支えるパターンなどを指す。 Clean Architectureもアーキテクチャパターンとして関係はする。しかし、マイクロサービス同様、DDDといいながらClean Architectureの話をしている場合がある。分けて考えるべきである。

要求分析

DDDの初学者が苦しむ原因の二つ目は、プログラミングスキルの向上を目論んでDDDに取り組むせいだろう。 DDDはウォーターフォールでいうところの上流工程から実装までの間にできる断絶をなくすことが目的である。現にエヴァンス本の第3章で「アナリストのモデルが役立たずで、開発者が設計をやり直した」、「プログラマと分断されたせいで、モデラ（エヴァンス本人）の作成したモデルの意図が伝わらなくなった」といったことが書かれている。

それ故に、実践的モデラの帽子をかぶる人間はプログラマとしてのスキルだけでなく、アナリストとしてのスキルを持っていなければならない。実践的モデラの帽子をかぶる人間全員がそのスキルを持つ必要はないだろうが、一人もいないならDDDを実践することはできないだろう。

「アナリストとしてのスキルが必要」という主張に性急な印象を持っているかも知れない。しかし、そもそもドメインもモデルも要求分析やビジネスアナリシスの文脈で使われる言葉である。

問題領域分析の実務家にとっては領域とは，特定のアプリケーション分野（資源管理，航空機予約，銀行業務，生産管理など）ごとに，システムを一般的に表現したクラスのことである．

（中略）

ひとまとまりのものとして考えると都合が良いものや，ある程度世界の他の部分から分離して考えることができるものを，ここでは領域と呼んでいる．

ソフトウェア要求と仕様 > 領域（Domains)

ドメイン

分析の対象となる問題領域。ある組織の全部または一部、およびその組織とやりとりする外部のステークホルダーなど。

ＣＢＡＰ／ＣＣＢＡ　ビジネスアナリシス認定スタディガイド(下) p.306

モデル（model）

現実を単純化して表現したもの。特定の受け手に情報を伝達し、分析とコミュニケーションと理解を支援するために作成する。

ビジネスアナリシス知識体系ガイド (BABOKガイド)Version2.0 p.236

ビジネスドメインモデル（business domain model）

組織のミッションにとって重要な意味を持つプロダクト、成果物、イベントに焦点を当てて見た企業の全部または一部の概念ビュー。

ビジネスアナリシス知識体系ガイド (BABOKガイド)Version2.0 p.234

ステークホルダーと話しながらモデリングすることでドメインモデルを明らかにする、というのはビジネスアナリストの役割に他ならない。

ところで、よく「DDDは大規模なプロジェクトでないと使えない」というようなことを見聞きする。しかし、これは不正確でより正しく言い換えるなら「DDDは複雑なドメインモデルを抱えているプロジェクトでなければ使う価値がない」となる。ちょっと込み入ったCSVのインポート、エクスポート機能があるなら、そこだけ軽量DDD化させることもできる。

実践的モデラとして必要なスキル

すでに書いている通り、プログラミングのスキルとアナリストとしてのスキルが求められる。アナリスト（ビジネスアナリスト）としての仕事や必要なスキルはカール・ウィーガーズのソフトウェア要求　第3版の第4章ビジネスアナリストにまとまっているので、そちらを参照してもらいたい。

いくつか特記しておくならば、どれほど技術スキルが高かったとしても、以下のようなタイプならアナリストには全く向かない。

ステークホルダーとのやりとりで、書いてあることや聞いたことをそのまま受け取る
ステークホルダーとのやりとりで、矛盾や不整合を見抜けなかったり注意を払わない
ステークホルダーとのやりとりで、コミュニケーション方法を相手に合わせない

ようは、ヒューマンスキルやコミュニケーションスキルなどのいわゆるソフトスキルに難のある人は実践的モデラとして振る舞えないということである。

DDDというグルーを忘れて各要素に分けて考え学ぶ

DDDという一塊で認識すると学ぼうにもエヴァンス本、IDDD本を読むほかに手がなくなる。しかし、分けて考えればずっと視野が広がる。

要求分析

上流工程だの要求分析だのと言われて暗い気分になっているかもしれないが、実際にはこれは福音である。

エヴァンス本を読んでも、ユビキタス言語、Entity、Aggregate、ValueObjectなどをどうやって発掘するのか具体的な手法は書かれていない。せいぜい、ドメインエキスパートと話して、モデリングして、リファクタリングして試行錯誤して発見していく程度である。

しかし、古典的な要求分析であれば用語集とデータディクショナリ、データモデリングなどプラクティスは存在する。用語集はユビキタス言語、データディクショナリはValueObject、データモデリングはEntityとAggregateに対応し、これだけで全てとは言わないが各々の候補を洗い出せる。実践的モデラとして振る舞いたいなら、自分はプログラマだからと避けて通らず、要求分析について学ぶことをおすすめする（書籍ならカール・ウィーガーズのソフトウェア要求　第3版がおすすめである）。

手前味噌だが、DDDを要求分析のプラクティスで突き詰め、体系化したのが要求分析駆動設計になる。

アーキテクチャパターン

アーキテクチャパターンは、エヴァンス本に書かれているパターンを押さえておけばよい。オプションでドメインイベントも押さえておいてもよい。それ以外のパターンはマイクロサービスのパターンと割り切る。

実装の基礎力が足りないのならCode Complete 第2版上、Code Complete 第2版下に書かれているような内容を身に付けるべきである（ストレートにCode Complete 第2版上、Code Complete 第2版下を読めと言わないのは、著作権について学びたいなら法文を読めというような感覚に近いからである。時間と体力と金と消化できる読解力があるなら読めば良い）。

ソフトウェアアーキテクチャの基礎力が足りないなら、Clean Architectureなどに書かれているような内容を身に付けるべきである（歯切れが悪いのは、個人的にロバート・マーチンの本は読みづらいと感じているからなので、買うなら中身を確認してからにして欲しい）。

エヴァンス本に無いアーキテクチャパターンについて学びたいなら、PofEAAを読むのが良いと思うがAmazonのレビューを見てから買うかどうか判断してもらいたい。

マイクロサービス

マイクロサービスについては、まともに物を言えるほど経験も知識もない。なので、以下の話は私の印象レベルの与太話である。

私の印象としては、非モノリスでシステムを分割してるなら「フロントサービスが2つあって、バックサービスのREST APIを叩くだけのシステム」から「コンテキスト図がないと全く全容が掴めない、数十のサービスがメッセージベースでやりとりするシステム」までひっくるめてマイクロサービスと呼ばれているように思う。それも、モノリスを打ち崩す銀の弾丸としてだ。「モノリス」と「前者よりのマイクロサービス」、「後者よりのマイクロサービス」の各々で求められるものが全く異なる別世界のはずであり、モノリスの延長で考えると痛い目にあうのは容易に想像がつく。

規模によって求められるレベルは変わるだろうが、それでもモノリスに比べてレベルの高い以下の人員が必要になるだろう。

システム全体を掌握できるアーキテクト
複雑なシステムの面倒をみれるSRE
モノリスなら不要な各種概念（分散コンピューティングの落とし穴、サービス間通信、サーガ、イベントソーシングなど）を理解したプログラマ
開発、テスト、検証、本番の各種環境の構築、維持のできるエンジニア

全社員数が100人に満たない会社のCTOが自社サービスをマイクロサービスにしたいと言っているのを聞いたことがある。ハイレベルかつ離職しないエンジニアが何人いるのか次第だが、100人未満の企業だと上記の人員を揃えて確保し続けるのは難しいのではないだろうか。

数十万行のRailsモノリスシステムをマイクロサービス化させようというエントリも見かけた。数十万行の経験はないが、数万行規模ならDDDを使えば十分モノリスで通用するだろうというのが実感である（やんごとなき理由で開発者が私一人でテストコードなしの数万行のRails2プロジェクトをRails5に上げる仕事をしたことがある。テストコードを書く余裕とDDDでリファクタリングする余裕があったら、全体の詳細な仕様まで把握することは可能だっただろうと思っている）。

DHHがThe Majestic MonolithというエントリでBasecampの規模感を紹介しつつ「マイクロサービスとかでかい企業向けだし、小規模組織が真似てもカーゴカルトでうまくいかないんだからモノリスで行こうぜ」という感じのことを言っている。具体的なBasecampの行数は出てこないが、おそらくは10万行には満たないだろう。

しかし、十倍規模の数十万行となるとモノリスで行けるかはわからない。コード行数がプロジェクトに与える影響は線形ではないからだ。本格的なマイクロサービスを必要とするかも知れないし、シタデルアーキテクチャで十分かも知れない。

個人的には、マイクロサービスは大企業のための高級品と思って忘れ、チーム編成のためでなくシステム要件に駆られてシタデルアーキテクチャ化していくのが現実的だろうと考えている。シタデルアーキテクチャも言ってしまえば小規模なマイクロサービスと言えるのだが、無形のマイクロサービスに比べればずっと理解が容易である。

その上で、マイクロサービスについて学ぶならという話がしたいところであるが、ビジネスアナリストよりのプログラマでしかない私にアーキテクトやSREとして学ぶべきことを語れるはずもなく。しいて言えば、マイクロサービスがどんな感じのものなのか把握したいのであれば、マイクロサービスパターンなどを読むのが良いだろう（本格的にマイクロサービスに取り組もうと思っているなら不十分だと思うが）。また、プロジェクト運営についてはMore Effective Agileの「第10章より効果的なアジャイル：大規模なプロジェクト」を読んでおくことをすすめる。小規模なプロジェクトのやり方をそのまま大規模なプロジェクトに適用することはできない。

文中で言及した書籍について

以下の書籍はおそらく経験3年未満の人では消化できないだろう。十分に経験を積むまでは手を出さない方が良い。

BABOKはビジネスアナリシスにおけるPMBOKである。ビジネスアナリシスについてはソフトウェア要求　第3版で用が足りるしずっと読みやすい。それに中古でしか出回っていないので、以下の本はよほどの物好きでなければ買わなくて良い。ちなみに、BABOK Version3の英語版はAmazonで買える。日本語版はIIBA Japanのオンラインストアで買える。