DDD の各層の関心事

最近 DDD(ドメイン駆動設計) に関する文章を書いては調べて、調べては消して…ということを繰り返していました。
そのうちに DDD の各層ってこういうことか、ということがわかったので共有します。

ドメイン層

一言で言えば「事業領域(ドメイン)を表現する層」です。
事業領域は事業の隅から隅まで全部表現しなくて OK です。
ソフトウェアとして表現しようとしている事業の範囲が事業領域、つまり、ドメインです。

ドメイン層で何をするかというと、事業内容をコードにします。
今の事業でこんな事をしている、これからこんなことをしようとしている、ということをコードにします。
事業内容がわからなければわかる人に聞きましょう。言葉の意味もすり合わせておきましょう。

表示方法とか、データの保存とかは、ここでは考えません。
他の層を気にすることはありません。

ドメイン層が関心を示すのは「事業」だけです。

データ層

一言で言えば「ドメインモデルを永続化する層」です。
リポジトリから渡されるデータを永続化します。
または、その永続化されたデータを復元しモデルとして返します。
永続化の手段は問われません。

事業は続くものです。
昔のファミコンのように電源を入れ直したら最初からやり直しということはありません。
ソフトウェアのデータもずっと保持し続けられれば良いですが、すべてのデータをメモリに載せ続けておくわけにはいきません。
そのためにドメインのモデルを永続化します。まるでドメインがずっと続いているかのように見せるために。

永続化・復元はしますが、事業に関わるようなことはしません。
ただただシンプルにドメインモデルを永続化するだけです。

データ層が関心を示すのは「永続化」だけです。

プレゼンテーション層

一言で言えば「ユーザーとのインターフェース層」です。
(当たり前のことを言ってますね…)
ユーザーという言葉は、クライアントと表現しても良いかもしれません。

プレゼンテーション層はユーザーに情報をわかりやすく表現します。
また、ドメインの機能にアクセスするための操作方法を提供します。
ユーザーはプレゼンテーション層を通じてのみ事業に関わります。
ユーザーは社員かもしれませんし、お客さんかもしれませんし、あるいは別のソフトウェアかもしれません。

プレゼンテーション層が関心を示すのは「事業の表現」だけです。

アプリケーション層

一言で言えば「事業をアプリケーションにする層」です。
ドメイン層だけではアプリになりません。
もちろんデータ層、プレゼンテーション層だけでもアプリにはなりません。
それらをつなぎ、アプリケーションとして成立させるのがアプリケーション層です。

ユーザーは事業に対して要求があります。〇〇をしたい、と。
ユーザーの要求をプレゼンテーション層から受け取り、それをドメイン層にわかる形で伝え、ドメインモデルの変化をデータ層に依頼して永続化し、再びプレゼンテーション層へ結果を返します。
全部やります。層をすべてつなぐため、ユーザーの要求ごとにユースケースとして分かれることが多いでしょう。

アプリケーション層が関心を示すのは「ユーザーの要求」だけです。

さいごに

これが自分が感じた DDD の各層の役割です。
各層の関心事をきちんと意識することで、すっきり層ごとに分かれた設計ができるのではないかと思いました。