『エリック・エバンスのドメイン駆動設計』読書メモー第4章

今回は『エリック・エバンスのドメイン駆動設計』の第4章のメモを紹介する。
出版された4月に比べてDDDの盛り上がりも一段落しているけれども、それは重要度が低くなっていることを意味しない。

今回もメモなので乱筆な部分を多く含んでいると思うので、ツッコミ、質問をもらえると非常にありがたい。

第4章の核心は、「ドメイン」を隔離することだ。
作業としてではなくて、プログラムの構造として隔離する。

紹介されているのは、レイヤ化アーキテクチャ、そして、レイヤの種類とアンチパターンとして「スマートUI(ユーザーインターフェース)」だ。

重要なことは、レイヤ化されたアーキテクチャにおいて、
・ユーザーインターフェース層
・アプリケーション層　
・ドメイン層（モデル層）
・インフラストラクチャ層
をわけることであり、ドメイン層にビジネスルールや知識を集中させることだ。

僕の理解では、ドメイン層を分離すること、そして、ドメイン層にビジネスルールや知識を集中させることは、単純に「変化させやすい」ことを目的にしていると思っていた。

ドメイン層を切り出し、ドメイン層にビジネスルールや知識を集中させることは、コードの可読性を上げると共にシステムそのものを理解しやすくなる、という利点がある。

各層の僕の理解は以下のとおり。
・ユーザーインターフェース層
→　画面、コントローラー。

・アプリケーション層　
→　アプリケーションを動かすために必要なロジック。外部システムとのインターフェースやアプリケーションの制御を行うロジックがある。

・ドメイン層（モデル層）
→　ビジネスロジック、知識をもつ。

・インフラストラクチャ層
→　ORマッパなどの永続化、メッセージ送信など、システムが扱うデータのI/Oの処理そのものを担当。

ちなみにレイヤ化アーキテクチャというのは、下位層にのみ依存するのが正しい姿だ。

上記の場合は、インフラストラクチャ層がひっくりがえってしまったら、最悪UIまで影響をおよぼすことも致し方ないが、UIをいじっただけでドメイン層の設計やコードまで変更になるようではいけない。

4章の後半でアンチパターンとして取り上げられる「スマートUI」では、各層のコードを混ぜて書いてしまうことで、ユーザーインターフェース層を修正、追加すると同時に、ドメイン層のコードが影響をうけてしまう弊害を指摘している。

「スマートUI」はその名前から受ける印象とは逆で、アンチパターンだ。

すべてのコードがつまった画面は賢すぎるために、さまざま弊害を生む。
他のアプリケーションとの統合が困難になり、変更やリファクタリングがやりにくく、なによりも複雑なコードになり理解しづらくなる。

もちろん利点もあるが、それは実際にシステムを作ることに置いては、ほぼ不要な利点なので紹介はしない。

すくなからず、「スマートUI」は現実、多くのプロジェクトで行われている一方で、多くのプロジェクトを苦しめている原因となっているものだ。

では、なぜ選択されてい続けているのか。
紹介しない不要な利点、がまさにそれにあたる。それは、本書で確認されると良いと思う。

また、レイヤ化アーキテクチャとスマートUIとの中間として、トランザクションスクリプト、というアーキテクチャも紹介されている。

トランザクションスクリプトとは、ユーザーインターフェース層は分離するものの、ほかの部分は分離しないような設計だ。
文面からは、トランザクションスクリプトを推奨する意図は感じられなかった。
それはやはり、柔軟性にかけるからだろう

ドメイン駆動設計が目指すものは、複雑さを柔軟性によって攻略することだ。

しかし、ドメイン駆動設計を行いたいなら、ドメインが切りだされているプログラム構造が不可欠だ。

そのため、もしも自分のシステムが複雑だと思うのであれば、スマートUIもトランザクションスクリプトも現実的な選択肢に含まれないはずだ。