Reading: エリック・エヴァンスのドメイン駆動設計
ドメイン駆動設計を開発に取り入れようとしたら、やっぱりこの原著は避けられないのだと、そう感覚が告げるので、読んだ。
正確には読もうとしたのはこれが3度目で、過去2回は序盤を読み下しているうちに関心がなくなってしまった。
今回は幸い、松岡さんの入門書（『ドメイン駆動設計 モデリング実装ガイド』）を読んだ後なので、多少は耐性がある状態から始められているのが幸い。
で、どうにか読み終えたけれど、特に後半2/3はやや読み飛ばし気味だったし、何度も寝落ちもした。
なので、本当に部分的なエッセンスしか得られなかったと思うけれど、ひとまず手元ですぐに使えそうとか、発見だと思えた部分はメモしている。
ドメインモデルとは特定の図ではなく、図が伝えようとしている考え方である。これはドメインエキスパートの頭の中にある単なる知識ではなく、その知識が厳密に構成され、選び抜かれて抽象化されたものなのだ。
出典：エリック・エヴァンスのドメイン駆動設計 p.2
常に覚えておいて欲しいのは、モデルは図ではないということである。図の目的は、モデルについてコミュニケーションし、説明するのを助けることにある。
出典：エリック・エヴァンスのドメイン駆動設計 p.36
これは読んでいてドメイン駆動設計を少し好きになる瞬間だった。ユースケースモデルと同じだと思う。
ユースケースモデル、と聞いて大抵の人が思い浮かべるのは棒人間と長い丸の中にあるユースケース、もしかしたらそのユースケースのコンテキストを示す四角い囲みもあるかもしれない。
ただ、どの書籍か忘れたけれど、ある書籍で「大事なのはこの図ではありません。ですので、ここで書いているユースケース名（＝長い丸）の中身を文章にしましょう。」と語れていたのを思い出す。実践が必ずしもできていないけれど、ユースケースモデルを書くときは必ずこれを思い出してる。
ドメインモデルというのも同じで、そういう意味で、データモデルと仕上がってきた図は近しいものになることもあるかもしれないけれど、明確にそれが示したいものが違うのだということがこの二文で表現されていると思う。
ユーザインタフェース（またはプレゼンテーション層）：
ユーザに情報を表示して、ユーザのコマンドを解釈する責務を負う。外部アクタは人間のユーザではなく、別のコンピュータシステムのこともある。
アプリケーション層：
ソフトウェアが行うことになっている仕事を定義し表現力豊かなドメインオブジェクトが問題を解決するように導く。このレイヤが責務を負う作業は、ビジネスにとって意味があるものか、あるいは他システムのアプリケーション層と相互作用するのに必要なものである。
このレイヤは薄く保たれる。ビジネスルールや知識を含まず、やるべき作業を調整するだけで、実際の処理は、ドメインオブジェクトによって直下のレイヤで実行される共同作業に移譲する。ビジネスの状況を反映する状態は持たないが、ユーザーやプログラムが行う作業の進捗を反映する状態を保つことはできる。
ドメイン層（またはモデル層）：
ビジネスの概念と、ビジネスが置かれた状況に関する情報、およびビジネスルールを表す責務を負う。ビジネスの状況を反映する状態はここで制御され使用されるが、それを格納するという技術的な詳細は、インフラストラクチャに移譲される。この層がビジネスソフトウェアの核心である。
インフラストラクチャ層：
上位のレイヤを支える一般的な技術的機能を提供する。これには、アプリケーションのためのメッセージ送信、ドメインのための永続化、ユーザインタフェースのためのウィジェット描画などがある。インフラストラクチャ層は、ここで示す4層間における相互作用のパターンも、アーキテクチャフレームワークを通じてサポートすることがある。
出典：エリック・エヴァンスのドメイン駆動設計 p.68 より表形式の内容を表示方法を変更して記載
これは先に読んでいた実装ガイドの内容が頭にあると理解がすごくしやすいと思う。自分はオニオンアーキテクチャーが一番しっくりきているので、インフラストラクチャー層の位置付けが少しこのレイヤードアーキテクチャーとは異なると思うけれど、それぞれが持つべき責務については変わらないと理解している。
ちょっと実装よりの話になってしまうのだけれど、オニオンにしろレイヤードにしろ、この構成に従ったとき、今時のアプリがどういった構成になるのかはちょっとまだ疑問が解けていない。
何を言っているかというと、例えば自分がよく取り扱うアプリだと、WebをTypeScriptで書いて、WebAPIはRESTful APIかGraphQLにして用意し、当該APIの内部でDB等に繋いでデータを返したり永続化したりする。
この場合、WebAPIの部分だけを考えるのならすごくしっくりくる。プレゼン層にはエンドポイントの記載、アプリ層にはユースケースを記載、そしてドメイン層でビジネスルールや制約を書いて、リポジトリパターンを通してインフラ層を利用する。
これをクライアントサイドまでに適用すると、どうなるのだろう。特に今時はReactやAngularなどのフレームワークでサポートしている振る舞いがあることもあって、上手くハマるのかはちょっと手を動かさないと想像では補えなかった。
ドメインエキスパートの使う言葉に耳を傾けること。何か複雑なものを簡潔に述べている用語がないだろうか？ドメインエキスパートに言葉の選び方を（たぶん、角が立たないように）正されていないか？あなたが特定のフレーズを使った時に、ドメインエキスパートたちの困惑した表情が消えることはないか？これらは、モデルにとって有益になり得る概念を示す手がかりである。
出典：エリック・エヴァンスのドメイン駆動設計 p.208
これは自分に経験がありすぎて耳が痛い。
この書籍を通じてこの後も、簡単なスキットなどがあり、開発者とドメインエキスパートのやりとりがある。
アプリを作ることに奮闘するばかりに、エキスパート側の言葉をお座なりにしてしまったり、自分の理解でドメインへの理解を実装に移してしまうことがあったし、多分これからもあるだろうと思う。その時にこの言葉を思い出して、書籍の中の言葉で言う「ユビキタス言語」を使うようにしていけたらと思う。
読んでいて地味に苦痛だったのはデザインパターンの適用例との対応の箇所。
電子書籍で読んだ都合なのかもしれないけれど、コードもやや読みづらかった印象。むしろ、コードが読みづらかったから苦痛だったのか？は自分でもよくわからないけれど。理解の助けにするためにはもう少しいい例がほしいと思った。
この書籍の後に出ている『実践ドメイン駆動設計』を既にチラ読みしているけれど、多少経験のある開発者だと考えたくなる、こういう場合どうするんだろう？といったガイドが盛り沢山のように目次を見た限りでは思えたので、やや食傷気味にはなっているけれど、楽しんで読んでみようと思っている。