ドメイン駆動設計というのが熱いのらしい

 

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

 

  ドメイン駆動設計というのが、なかなか良いのらしい。データ中心設計だとか人間中心設計だとか、いろいろなことが今まで言われてきたが、ドメイン駆動設計は、オブジェクト指向設計の流れにあって多くのプロジェクトで実践例が積み重なっているという。

 

 とはいえ、我々はドメインと言われても、いきなりピンとはこない。ドメインネームとか、領域とか、そういうイメージになってしまう。だがドメイン駆動でいうドメインというのは、ビジネス領域のことであるようだ。ビジネスロジック、業務フロー。だからむしろ、ビジネス駆動設計とか業務概念駆動設計(でまかせの造語)とでもいわれたほうがピンとくるかもしれない。

 

qiita.com

 この[DDD]とも略されるドメイン駆動設計は、レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャ、オニオンアーキテクチャ、そしてクリーンアーキテクチャという風に徐々に整理・進展してきており、業務モデルを核とした階層化されたモデルとしてアーキテクチャを設計していく考え方のようである。

 

 と、まあここまで来ても、じゃあ実際には何をすればいいのか? という感じになるかもしれない。理想論、机上の空論にすぎないのではないか? 現実はそんなにシンプルではないのではないか? と。

 

nrslib.com

 

 が、上の記事をみると分かるのだが、ドメイン駆動設計は実装に落とし込むことができる思想で、再利用可能、交換可能、メンテナンス容易な部品群を簡単に組み上げられるような形で作り込み組み上げていけるらしいのだ。

 

 依存関係を一方向に限定することで改修時の影響範囲を最小化し、利用方法を分離することで下位レイヤーを交換可能にし、変更の多い箇所の変更で全体が影響を受けにくく、コアな部分のビジネスドメインの変更については、逆に少ない修正で全体に浸透しさせられる。理想の設計モデルである。

 

 エンティティが中心にくる、ということで、実際にはデータ中心設計に親和性があり、ユースケースが高いレイヤーにいるということで人間中心設計にも親和性があるのかもという気もする。

 

 Laravelでドメイン駆動設計という例があった。

qiita.com

 

 一方でEric Evans氏自身はドメイン駆動設計は未だに未完成だと述べてもいる。

www.infoq.com

 

 そんなわけで、完成された万能の理論とまでは言えないわけなのだろうが、無から理想の設計をひりだそうとして先人らと同じ轍を踏むぐらいであれば、まず過去の歴史を反映して進化してきたものに学び、取り入れていくのがよさそうだ。

 どのような設計が理想であるかというのは、対象ビジネスのスケールや変化しやすさなどにも左右されるかもしれない。メンテナンス容易さ、維持しやすさ、アップデートしやすさ、移植しやすさ、改修しやすさ、などが必要であるならば、それを実現するためにどのような設計が理想なのか、今最も熟れた設計思想から学べるものを吸収し、取り入れていくことはかならず有益な結果を生むような気がする。