DDDとは
以下wikipedia参照。
ドメイン駆動設計
（英語: domain-driven design、DDD）とは、ドメインの専門家からの入力に従ってドメインに一致するようにソフトウェアをモデル化することに焦点を当てるソフトウェア設計
手法である[1][2]。オブジェクト指向プログラミングに関しては、ソースコード（クラス名・クラスメソッド・クラス変数）の構造と名称がビジネスドメインと一致させる必要があることを意味する。例えばローンの申し込みを処理するソフトウェアには、LoanApplication
やCustomerなどのクラスと、AcceptOfferやWithdrawどのメソッドが含まれることになる。
結論、ざっくばらんにいうと、
チーム開発のために用いられた保守性を担保するための機構。
保守性とは、役割分担されたクラス設計や構造のことを指しています。
まだモヤモヤしてる感じでしょうか。
それでは、更に深掘りしてみていきましょう。
MVC構造
DDDのメリットを理解するためにはまずMVC構造の理解、MVC構造に沿ったオブジェクト指向型の開発経験が要求されます。
以下のイメージはJAVAによるMVC構造ですが、言語は関係ありません。
極端な例ではありますが車の製造工程をイメージしてみるとわかりやすいかもしれません。
車を作るという要求に対して、同じ工場（プログラムファイル）で処理をすることに変わりはありませんが、それぞれのライン（層）で役割が明確に決まっており、一連の流れ（MVC）を経て、ユーザーへお届けできる状態を作り上げます。
MVCはこのように役割を分散し、ある種のキャパオーバー（肥大化）を防ぐ構造体のことを表していると言えます。
MVC + DDD
MVC構造で開発していても機能が重ければ処理する内容も増えるので必然的にcontrollerに処理が密集してしまいがちです。
controllerに処理が集まってくるとなんとかして分散したいと人は考えるようになるわけですが、
経験の浅いエンジニアが真っ先に考えつく方法はcontrollerの処理をviewとmodelに分散させようとします。
controllerに書くようなビジネスロジックをmodel側に書いたり、
controllerで制御するようなものをview側で制御するようになります。
しかしこれは根本的な解決にはならず暫定的な対応に過ぎません。
プロダクトが成長し、機能ブラッシュアップを繰り返すと、分散したはずのcontrollerの処理が増え、再度controllerの処理をviewとmodelに分散させようとするイタチごっこが始まり、後にファットコントローラーと言われるようになるのです。
ここまでプロダクトが成長してくると、もはやMVCの層だけでは足りず
プロダクトの成長に応じて、必要な層をデザインして保守性を高めていくことが求められます。
プロダクトというのは基本的に成長するので、最初から王道デザインパターンを当てはめて開発していた方が良いというのが結論です。重要事項ほど先に決めておくお話は有名ですね。
また、MVCというのはシステム開発におけるレイヤー設計でデザインパターンとも言われています。
デザインとは、単なる視覚や感覚のことではない。
デザインとは、どうやって動くかだ。
それぞれの空間にどういう責務を担わせ、どうやって動かすかをデザインするのもDDDですね。
イラストレーターやアニメーターの経験がある方は馴染みがあると思いますが、ぱっと見１枚の絵でもその絵は複数のレイヤーによって構成されています。レイヤーをどの粒度で分けるなど明確な決まりはありませんが間違いなく言えることは、全て１つのレイヤーに詰め込むと複雑なマテリアルほど修正が難しくなるということです。
車の製造工程やイラストの構造を例に挙げましたがDDDは色んな業界で駆使されています。
以上を踏まえ、DDDとは 任意の空間を定めて、空間毎に役割を設定してあげて役割分担できる構造の上でお仕事していこうねー、 という設計手法のことです。