🚀

DDDドメイン駆動設計とは何なのか?

2023/03/27に公開

はじめに

ドメイン駆動設計について数か月ほど本を読み漁ったため、
個人的に感じているドメイン駆動設計とは何なのかなというのを今の感覚を記述しておこうと思います。
ずれた記述している可能性もありますがご容赦願います。


もくじ

1.ドメイン駆動設計とは何なのか?
2.ドメインを抽出するには
3.個人的なDDDの別視点


1.ドメイン駆動設計とは何なのか?

定義的な側面では、ソフトウェア開発手法の1つであり、基本的にコードの話はメインではありません。名前の通り設計の話です。

もちろんコーディングも必要なパーツではあるのですが、
一番目指したいことは問題を解決するための事柄をソフトウェアから抽出することです。抽出することでこのソフトウェアが何に対してどうやって問題を解決しようとしているかが具体的になりリソースを割く場所も明瞭になるという流れです。
(この抽出したものをドメインとよんでたりします)

また抽出するためにエンジニア(プログラマー, デザイナー)だけでなく、経営者、営業、クライアントもプロジェクトに関わる人全員を巻き込める形にして言葉を共通化することで、現代の複雑なソフトウェアの課題に取り組もうという流れがあります。
(全員で同じ共通化言語でコミュニケーションを取ることをユビキタス言語と言います、ドメインついて詳しい人のことをドメインエキスパートと呼んだりこの辺は意味だけ関連図けて覚えなくていい)

2.ドメインを抽出するには

じゃあどうやって抽出するんだ?となると思いますが、そこでようやくコーディングです。
DDD、軽量DDD、アーキテクチャ周りで調べていただくと色々出てくるかと思います。。。
レイヤードアーキテクチャ
クリーンアーキテクチャ
オニオンアーキテクチャ
ヘキサゴナルアーキテクチャ
一体どれがいいんだよとなります。正直どれでもいいかなと思っています。

極端かもしれませんが、
オブジェクト指向設計されたロジックレイヤー層とUIレイヤー層が明確に分かれている。認識できているのであればなんでもいいのかなと思ったりしています。
そこにプラスしてDDD Referenceのデザインパターン(ValueObject, Entity, Repository, Factory等)を利用するとよりドメインが抽出しやすくなるみたいなイメージを持っています。
→ これをわかりやすく大衆化したのがオニオンとかクリーンの個人的なイメージ。。

3.個人的なDDDの別視点

個人的な主観が入るためネット記事だな程度で聞き流してください。

DDDを分解すると、、、
ドメイン駆動設計 ≒ オブジェクト指向開発 + ユビキタス言語による共通認識設計による抽出
オブジェクト指向開発 ≒ 軽量DDD
な見方をできるかと思っています。

厳密には違うのは承知してますが、的外れほどではないみたいな感じかなと。

個人的には、、、
ドメイン駆動設計は

プログラミング側で構造化プログラミングのパラダイムシフトが起きたように、、
goto → 3つのルール(順列,選択,反復)のようにあえてルールを入れて制限をかけることで進化した時と同じ感じなのかな?

今まで自由にできていたソフトウェアの設計に対して、あえて制限(ドメイン)をかけてルールを設けることで、開発しているソフトウェアに対してより根幹となる成果と向き合って成果を得やすくしようとしてるのかなと考えていたりします。

要するに設計側のパラダイムシフト的なニュアンスを感じてます。。。

まだ道半ばの理解で、
説得力がないものではありますがどなたかの参考になれば幸いです。

Discussion