読者です 読者をやめる 読者になる 読者になる

Screaming Loud

研究・プログラミングなど気づいたことをメモをしています

ドメイン駆動設計についてのまとめ その1

DDD(ドメイン駆動設計)) プログラミング

ドメイン駆動設計について勉強・実践しているため、そのアウトプットととして、まとめていきたいと思います。

【ソフトウェアはなぜ作る必要があるのか?】

大前提として、ソフトウェアはなぜ作るのか?ということを認識している必要があります。

【なぜ導入するのか?】

ソフトウェアを導入する真の目的は、そのドメインの業務をより効率化するためです。

この認識を忘れがちですが、結局「はい作った」ということではダメで、ユーザが使いやすいものでないといけません。

【なぜ設計手法があるか?】

データベースアクセスやクライアントとの橋渡しであるコントローラー部分に関しては、ライブラリなどが豊富でサポートをしてくれる部分が大きいです。
しかし、実際のソフトウェア固有の挙動を制御するビジネスロジックに関しては、各業務の要件に関わるので決まった実装法がないという状況です。

そこで、設計手法という枠組みを立てることによって、その業務に依存した部分を実装しやすくするとうことです。

そもそも設計とはなにか?という問いには、以下を読んでみるといいかもしれません。
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!

ドメインとは?】

DDDの本などでは、アプリケーションが対象とする業務領域(知識、影響力、活動の領域)と書かれています。

これだけだと分かりづらいと思います。

まずドメインとは、「特定の業務領域」のことを指します。エンジニア固有の単語ではないので、広く一般に使われる単語と認識してもらえるとわかりやすいかと思います。

例えば、銀行システムであれば、銀行口座の金の出し入れはどうなっているか?銀行の出し入れの集計はいつどういう風にやっているか?など、現場の固有の人しか知らない領域のことです。

なので、ドメイン駆動設計というものは、実際にソフトウェアを作るエンジニアやPMが知り得ない、ユーザの行動の効率化を駆動とした設計手法と言い換えることができるでしょう。

ドメイン駆動設計にすると、何がうれしいか?】

ドメインを深く理解しないで設計したソフトウェアは、ドメインの変化に対応しにくいはずです。

ドメイン駆動設計で作られたコードは、ドメイン固有の知識がなくても、モデルのコードを読むだけで理解できます。
そのため、保守性が高いといえます。

【どうやって設計を進めるか?】
ドメインを一番知っているひとは誰か?
×実装者 ×マネージャ ○実際の業務を行っている人たち

一番ドメインを知っている実際の業務を行っている人とのディスカッションを通じて、ドメインモデルを構築していくことが設計への近道です。


今日はここまでにしたいと思います。