『実践ドメイン駆動設計』を読んだ

日々の業務におけるコードレビューやMTGにて、ドメイン駆動設計の用語を使ったコミュニケーションがなされることがよくあるのだが、インターネットで検索して得た知識しか持ち合わせておらず理解に支障があったことや、設計に関する知識の行き詰まり感があり、ここらでドメイン駆動設計を体系的に学んでみようと相成った。「Eric Evansのドメイン駆動設計」を長いこと積んでいたのでこちらを読むか迷ったのだが、難解であるとの評判をよく目にしたので、より平易とされる「実践ドメイン駆動設計」を手に取った次第である。

一通り読んで、ふんわりとしていたドメイン駆動設計の用語、EntityやらValueObjectやらへの理解が深まった。 局所的な理解はそれなりにできた気がするんだけど、全体通しての理解度はそれほど高くないと感じている。 ネットワークにつながったコンピューターたちから送られてくる大量のデータの処理と保存というミッションにどう立ち向かうかについて書かれている気がする。それは自分の職務領域と微妙にズレているのでマッピングできたりできなかったりする。

「境界付けられたコンテキスト」というのもふんわり理解にとどまる。というのも、複数のサーバーサイドアプリケーションで構成される巨大なシステムを設計したことがないのでふわっと眺めていた。そのようなシステムを作る機会があったときにでも再読するとよさそう。 「モジュール」とか「ファクトリ」の項は馴染みがあるので理解しやすかった。開発機能単位でコードライブラリを分離したり、なんならGitリポジトリごと分けてしまったりして、インターフェースを介した疎な結合でもって利用されるようにする、といったことは自然とやっていて、合理性を確認できた。 ヘキサゴナルアーキテクチャーも自然と使っていたので馴染み深く感じた。依存関係の一方向性はわりと意識している。仕事で扱うコードベースがクリーンアーキテクチャでやっていくぞ、ということになっていたので、思想が染み付いている。ヘキサゴナルアーキテクチャーとクリーンアーキテクチャー、特徴が似通っているところがある。

自分は主にUnityとかのゲームエンジンを利用したシステムのクライアントアプリを開発してるのだが、その領域はユーザーインターフェースレイヤが肥大化したシステムと言えるのかもしれない。クライアントアプリ単体で巨大な一つの境界付けられたコンテキストと見ることができそう。ゲームエンジンのユースケースでは問題空間をどう捉えたらいいのだろう、とか考えた。「CG空間におけるキャラクターの行為」くらいの粒度でビジネス上の課題、というかユーザーに体験させたい体験を定義して、ドメインを定義するのかな、とか考えた。