ドメイン駆動設計の段階的理解

最近ドメイン駆動設計(DDD)の考え方を採用してるチームで開発している。

キャッチアップし始めて思うが、正直DDDは敷居が高いと思う。

本やネットの文献を見てみても、明確な理解できたとならない。理解の核をつき、明るい道筋を照らしてくれるような言葉は全く見当たらず、ただただ曖昧な記述のみが羅列されているように思える。(特に本で読むとその傾向を著しく感じる、著者は把握できてんのかな？伝える気あんのかな？って気さえする)

だが、読みする中でようやく一つの気づきを得た。

DDDの実戦には、３つの段階に分けられるのではないか？と

この気づきが初学者のDDDの全体像の理解、また個々の知識やテクニックの理解に役に立つことと嬉しい。

① ソフトウェアサービスにはサービス利用者の関心ごと(ドメイン)が存在する。我々はまずサービス利用者の関心ごとを理解し、またそれをより細かく具体的な関心ごと(コアドメインやサブドメイン)に分割して整理する必要がある。

② 整理されたコアドメインやサブドメインをオブジェクト指向的にドメインモデルとしてモデリングしていく。

③ ドメインモデルにドメイン知識が集約されるように設計、実装をしつつ、ソフトウェアを想定通りに動くように実装する。

① のために役立つ概念、テクニックがドメインや境界づけられたコンテキスト、ユビキタス言語とかの話で、このように分割、整理して理解することで、業務理解ひいてはビジネスへのインパクトも期待でき、またそれを元に実装もしやすくなると言われている。

② ここはドメインで使われている単語や振る舞いをそのままモデリングしろって位で、それ以上のことはない気がしている。

③ ドメインモデルを用いたデザインパターンの話だが、ドメインモデルを設計するのに助けになるデザインパターン、またドメインモデルとそれ以外を分離させつつソフトウェアを正しく動作させるためのデザインパターンに分けられると思う。