DDDっておいしいの？設計から実装まで

DDDってなに？

Domain-Driven Design

ドメイン駆動設計です。

Domainって？

google.co.jp

違います！

Domainとは

「知識、影響力、活動の一領域」

よくある参考

飛行機の運航制御のドメイン
「飛行機の運航制御には、出発地と目的地
は航路の始点と終点がある。
航路は出発地と発着地に関連する」

ユビキタス言語

このドメインから、

開発者とドメイン知識をもつ人（ユーザ、専門家等）

との間に共通言語を定義する
「始点（DeparturePoint）」

「終点(ArrivalPoint)」

「航路(Course)」

ユビキタス言語を使って会話してみる

ユビキタス言語を使うと

ドメインモデルと実装コードがきちんと対応付けられるようになる。

見えないものが見えてくる。

設計

ドメインモデルの設計を使うと

色々なところから呼ばれても、

常にドメイン層では同じことが行われるので、

関係なく使いまわせる。

また、フレームワークやミドルウェアに依存しない。

Springでサンプル

レイヤー分割

こうやって切り分けることで、別にドメイン部分ではドメインのことだけ考えられる様にする。

サービスによってドメイン内部をブラックボックス化

サービスを介してモデルを使うことで、インターフェース側はモデルのことを

知らなくていい。

リポジトリをつかってデータベースとモデルを切り離す

DBの値とかどう入っているかはモデルは知らない。

リポジトリさんがんばれ！

ドメインモデルの実装を使うと

それぞれのレイヤーで依存していないので、

• レイヤー間の単体テスト
• サービスを使った結合テスト

があればサーバー上から呼ばなくても値は担保できる。

結論：おいしいポイント

ユビキタス言語を使ったコードの現実化

　専門家にしか見えないものが見えてくる

レイヤー分けされた設計による可用性

　いろんな所から同じ処理を呼び出せる

レイヤー分けされた実装による安全性

　テストが描きやすい

　フレームワークの載せ替えも簡単

詳しく勉強される方はこちらで