読者です 読者をやめる 読者になる 読者になる

Shin x Blog

PHPをメインにWebシステムを開発してます。Webシステム開発チームの技術サポートも行っています。

より実践的なDDD本「.NETのエンタープライズアプリケーションアーキテクチャ第2版 」

.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)

DDD 関連の書籍といえば、Eric Evans の DDD 本( エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) )や、Vaughn Vernon の IDDD 本( 実践ドメイン駆動設計 (Object Oriented SELECTION) )が有名です。

DDDで登場する実装パターンや周辺知識をより実践的に解説しているのが、「.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)」(naa4e)です。

.NET 以外にも大いに通じる内容

本書は、.NET の名を冠しており、サンプルコードは、C# で記述されています。また、利用するライブラリも .NET 周辺のものであったり、解説で登場する RDBMS も、Web 系でよく登場する MySQL や PostgreSQL よりも、SQL Server や Oracle がメインとなっています。

しかし、.NET 固有の話はそれだけです。.NET 固有の内容は、枝葉の部分であり、メインの内容は、プラットフォームやプログラミング言語に関わらずとても参考になるものでした。

日頃、.NET 界隈にいない人間としては、正直、マイクロソフト公式解説書としての体裁になっているがゆえに避けてしまう人がいるのが、勿体無いとさえ感じる本でした。

DDDをガラスケースから日々実践するプラクティスへ

DDD 本、IDDD 本と本書を比べると、より実践に寄せた内容となっており、DDD をより身近な普段の開発に適用するために解説されています。

実際の開発では、上手くパターンにあてはめられなかったり、妥協してしまう場面もあるのですが、そのあたりも考慮に入れられています(トランザクションスクリプトも場面によっては有用なパターンである、など)。本書の表現を借りると、ヒーローがいなくても、一般の開発者が DDD 取り組む方法を示した本とも言えます。

それぞれ執筆された時期が異なる(DDD 本(2003年)、IDDD 本(2013年)、本書(2014年))ので、理論から実践、さらに実践した上で現実的な落し込みといった具合に、より現実的な内容に推移しているのが興味深いです。

私は、DDD 本、IDDD 本、本書の順序で読んだのですが、本書が一番理解しやすいと感じました。*1

本書の内容

本書の目次は下記です。

現代の設計手法や開発手法、OOPの基礎(SOLID原則など)やテスト手法からはじまり、DDDで利用されるパターンの解説に入っていきます。

本書で興味深いのは、第6章のプレゼンテーション層がドメインアーキテクチャのすぐ後に来ている点と、CQRS と イベントソーシング(ES)に多くのページが割かれている点です。

■第1部 基礎
第1章 現代のアーキテクトとアーキテクチャ
第2章 成功のための設計
第3章 ソフトウェアの設計原則
第4章 高品質なソフトウェアの作成

■第2部 アーキテクチャの考案
第5章 ドメインアーキテクチャの発見
第6章 プレゼンテーション層
第7章 伝説のビジネス層

■第3部 サポートアーキテクチャ
第8章 ドメインモデルの紹介
第9章 ドメインモデルの実装
第10章 CQRS の紹介
第11章 CQRS の実装
第12章 イベントソーシングの紹介
第13章 イベントソーシングの実装

■第4部 インフラストラクチャ
第14章 永続化レイヤー

ユーザエクスペリエンス(UX)ファースト

ソフトウェアの世界では、バックエンドから取り組むのが慣例となっていました。私たちの多くは、プレゼンテーションを システムのそれほど高尚な部分だと見ておらず、ビジネス層をデータアクセス層が完成してから取り組めばよい、という程度に考えていました。しかし、システムの複雑さを問わず、プレゼンテーションとバックエンドが等しく必要であることに疑問の余地はありません。

Webアプリケーションでもサーバサイドをメインにやっていると、プレゼンテーションの重要性は認識はしていても、重点をサーバ側に置いてしまいがちでした。

しかし、プレゼンテーションはユーザが直接システムに触れるインタフェースであり、ここからシステムのユースケースやタスクを見ていくというのは当然のことです。

自分が設計する際は、プレゼンテーションももちろん考えますが、どちらかと言えば、サーバサイドの設計を主に考えていた節があるので、ハッとさせられました。

CQRS を身近なパターンに

CQRSは、ソフトウェアアーキテクチャにおけるコロンブスの卵です ── すなわち、自明ではない問題に対する驚くほど明確でそつの ないソリューションです。開発者とアーキテクトは、DDDとDomain Modelの階層化アーキテクチャを理解し、正当化し、機械化すること に何年も費やしてきました。特に複雑なビジネスドメインでは、クエリスタックとコマンドスタックの両方をドメインモデルで実現する ことがきわめて難しいという問題と格闘してきました。 CQRSにより、すべてが一夜にして変わってしまい、複雑なビジネスドメインがはるかに管理しやすくなりました。

IDDD 本では、やや特殊なパターンとして解説されていた CQRS が、多くの場合に適用できる身近なパターンとして解説されています。

このあたりは、私もドメインモデルからクエリを分離して、クエリについては、DTOを返すリポジトリを作って実装した経験から、わりと使い勝手が良いパターンではないかという印象を持っていました。

本文では、単なる CRUD パターンでも、CQRS にしてコマンドとクエリの関心事を分けるのは意味があると書かれており、CQRS に興味がある人には参考になる内容でしょう。

イベントソーシング(ES)と似たものは、30年以上前からある

先に挙げたアプリケーションはどれも数十年前から存在しているもので、COBOLやVisual Basic 6でかかれたものさえあります。つまり、イベントソーシングなんて仰々しい名前が付いていても、決してソフトウェアの新しい概念の到来を告げるものではないのです。

新たな名前が付いたものが出てくると、身構えてしまいますが、実は従来からあるものに名前が付いてパターン化したものというのも良くあります。

その最たるものが、GoF でお馴染みのデザインパターンでしょう。イベントソーシングもこうした以前からあるものをパターン化したものです。

現実世界での出来事では、発生した事象が消えてなくなることはなく*2、事象をイベントとして残していくというのは特にユーザからすると理解しやすいものです。

例えば、商品購入を記録する場合、購入情報のドメインモデルを保存し、ステータスが変わる度にそれを書き換えます。そして、イベントを補足情報としてログに記録するというのは良くあるパターンです。

イベントソーシングでは、これを逆転し、イベントを記録する方を主とします。そして、保存したドメインモデルは、あくまでもスナップショットとして扱います。イベントには、必要な情報が全て記録されているので、原理的にはそれらを順に適用していけば、どの時点のドメインモデルでも再現できるからです。

実際にイベントソーシングを実装するとなると、パフォーマンスの問題は無視できないのですが、ここについても実装のアイデアが解説されています。

さいごに

DDD 本を読んで、自分たちが取り組んでいるプロジェクトに DDD を実践してみたい人や、実際に取り組んでみたもののまだしっくり来ない人に手にとって見てもらいたい本です。

ユーモアを交えて、平易な表現で書かれており、理解しやすいので、これから DDD を学ぶ人や OOP の基礎を見直す人にも良さそうです。

実装で具体的なイメージを持った状態で、理論に立ち返るとより理解が深まるので、この本から DDD 本や IDDD 本に戻るのも良いですね。

なお、この本を読んだ後に、Amazon でリコメンドされた「C#実践開発手法 (マイクロソフト公式解説書)」も気になる内容だったので、こちらも読んでみたいと思います。

.NETのエンタープライズアプリケーションアーキテクチャ第2版 .NETを例にしたアプリケーション設計原則

.NETのエンタープライズアプリケーションアーキテクチャ第2版 .NETを例にしたアプリケーション設計原則

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

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

実践ドメイン駆動設計 (Object Oriented SELECTION)

実践ドメイン駆動設計 (Object Oriented SELECTION)

*1:もちろん、それは前 2 冊を読んで、多少なりとも実践したからこそというのはあります。

*2:購入商品をキャンセルしても、購入した事実は消えない