日記マン

動画広告プロダクトしてます。Go, Kubernetesが好きです。

ドメイン駆動設計のドメイン駆動とはなにか

ここ最近の仕事は、かなり硬直化した自社サービスをリファクタリングしている。
そのなかでアプローチのひとつとして、ドメイン駆動設計を勉強して、取り組んでいる。
エバンスDDD本を手に取り、ネットで様々な知見を調べながらも、理解が定着してきている。
ここらでいちど、ドメイン駆動設計について、理解をアウトプットしておく。

おすすめの書籍・資料

エバンスDDD本や実践DDD本は初学はとても苦しんだ。
入門するなら、これらの本を手に取る前に、増田さんの素晴らしい資料たちがおすすめ。

  1. 増田さんのスライド, 増田本を読む
  2. エバンスDDD本、実践DDD本を読む

www.slideshare.net

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計 (Object Oriented SELECTION)

実践ドメイン駆動設計 (Object Oriented SELECTION)

この順番で学ぶのがいいと思った。

ドメイン駆動」設計 = ドメイン特化のモデル(型/クラス)設計

増田さんの再定義を引用する。

まず、ドメインモデル = 計算モデルは、DBに永続化されたデータモデルとは異なる。
データモデルは事実であり、計算モデルは事実ではなく加工。
プリミティブな値をそのまま扱わず、計算・加工・判定したうえでクライアントに返す。
それがドメインモデル(計算モデル)。
そしてドメインモデルがそのままプログラムコード上で独自設計した型/クラスに対応することが理想。

プリミティブなデータを独自に型付ける。
Goで計算モデルをどう書くか。
type 修飾子ですぐに実装できる。

i101330.hatenablog.com

プリミティブな型のほとんどは、とりうる値が大きかったり、知識が貧弱すぎる。
限定的な文脈で利用されるために特化された型を設計する。
それが、「ドメイン」特化のオブジェクト指向という理解。

ドメイン駆動設計の導入検討 = ドメインロジックが複雑かどうか?

アプリケーションに、ドメイン駆動設計を必要とするかどうか。
プリミティブなデータそのままではなく、ビジネスが要求する計算・加工・判定を要求する場合に有用。
データをそのまま参照したり保存したりする単純なCRUDアプリケーションだったら、特段ドメイン駆動設計を導入しなくてもよい。

「レイヤードアーキテクチャ」 = ドメイン特化の型を隔離する

  • プレゼンテーション層 = アクターへの表現を記述する
  • アプリケーション(ユースケース)層 = 機能要求のフローを記述する
  • データソース層 = 外部DBとの接続やDBロジックなどを記述する

これらの層から参照される、ドメインモデルが存在するドメイン層。
ドメイン特化のモデルこそ、アプリケーションの独自性そのもの。
ドメインに対する関心ごとが、
他の層に漏れないように、
他の層の責務がドメイン層に入り込まないように、
ドメインモデルたちを隔離をする。

ドメインモデリング = ドメインへの洞察を重ね、抽出し、再設計する

ドメインモデリングは一度では終わらない。

例えば自社プロダクトはアクターへのUI/UXの向上、
競合との差別化要因となるような新規機能の開発、
顧客、利害関係者の変化など様々な成長を必要としていく。
そのほとんどが、そのプロダクト特有のドメインロジックの新規実装・変更であることが多い。
(自分が手がけているプロダクトがそう。)

ドメイン層を隔離できていない場合は、そこで成長痛が起きて、複雑なドメインロジックがソースコードのあちらこちらに散在し、
変更容易ではなくなり硬直してしまい、結局は成長が止まってしまう。
(自分が手がけているプロダクトがry)

サービスをグロースさせていくために、
ドメインに対し深く洞察を繰り返し、新たなパターンを抽出し、ドメインモデルを再設計する。
これを繰り返していくためのフレームが、ドメイン駆動設計のモチベーションだと思う。

まとめ

自社サービスをリファクタリングしている現状の自分自身の実体験と絡めて、
ドメイン駆動設計が立ち向かっているビジネスの複雑さとはなんたるかがわかってきた。
ドメイン駆動設計とは、ドメイン特化の型設計であり、
レイヤードアーキテクチャは、そのドメイン特化型たちを隔離するフレームワークである。
自社サービスをグロースさせていくために、洞察、抽出、再設計していく。