ドメイン駆動設計

https://gyazo.com/1e07389b51a189ce70f4eee1687f2c5a

Entity と Value Object

全てのオブジェクトにはビジネスドメインに応じて同一性が必要か必要じゃないかという違いがある。

同一性をなんらかの形で表現したいものは Entity で 値によってその同一性を判断していいものを Value Object と区別する。

通常どんなモデルも同一性を持って Entity として表現したい衝動にかられるが、ソフトウェアは複雑なので複雑性を緩和するためにも、ドメインを強調するためにも同一性や追跡性が必要のないものを Value Objectとして区別すると良い。

集約

DDDでもOOPでもオブジェクトが命

オブジェクトには必ずライフサイクルがある、作成されたから破棄されるまで、DBに永続化されたり、要素が変更されたりなど様々な状態遷移をする。

そういったオブジェクトの集約を抽象化する方法として、Factory と Repository がある。

Repositoryは、集約ルートに対するオブジェクトのアクセスを抽象化するもの

全てのEntityに用意する必要はない

つまり集約ルートとその境界をビジネスドメインに沿って判断する必要がある

Repository : すでに存在しているオブジェクトを再構築する

Factory : 新規にオブジェクトを作成する

EntityとValue Object は混ぜてはならない

例えばデータの検索で「オブジェクトが見つからなければ、新しく生成されたものが返る」というのはEntityを取得しに行ってるのにも関わらずValue Objectが返ってきているので避けた方がよい

コンテキストとアーキテクチャ

コンテキストとはあるモデルを使うにあたって想定する前提や意味である。

同じモデルでも、アプリケーションによって使われ方が全く異なる場合がある。

例えばモバイルアプリでのマルチモジュールで機能ごとにモジュールを切ってる場合には、それぞれは別のコンテキストと呼べるかもしれない。

Layered Architecture

モノリスで平べったい場合には、再利用性が落ちる

またドメインが強調されなくなってしまい知識をコードから得ることが難しくなる。

技術的な詳細はそれはそれでレイヤーとして分離してしまい、ドメインに集中するための仕組み

https://gyazo.com/37307517ef3a5510a7dadf965c3a24cc

https://gyazo.com/acbb5251c557820b23423dbf74102044

境界づけられたコンテキスト

コンテキストによって境界を切って、そこでのモデルはそのコンテキストに特化したものを使おうというもの。

機能ごとに切ったマイクロサービスなどでよく見られる気がする。

例えば、認可ではユーザーの権限が気になるが、パーソナライズではユーザーの行動がメインのフォーカスになったりなど

多くの場合はこれに沿ってチームが編成されることがある

個人的には、チームという枠とプロセスが編成されるだけで、中の人材は流動的でいいと思う

共有カーネル

境界づけられたコンテキストで作業をしていると最初の方はあるコンテキストに閉じた設計で意図が明確なコードになるだろうけれど、そのうち共有したくなる部分も出てくる。

これを共有カーネルと呼ぶ。ここはコアドメインが入ってるところかもしれない。

腐敗防止層

コンテキスト外のサービスにはレガシーなものやサードパーティーのものなどコンテキストで使用するモデルの変換が自然にはできないことがある

とはいえ汚い実装をしてドメインの強調が薄まるのもいやなので、この変換層自体をレイヤーとして分離してうまく外側のシステムとやりとりする層のこと

例えば新しいモジュールがレガシーなインフラを使うなどが考えられる

気になった章

1部 : ドメインモデルを機能させる (1章 ~ 3章)

DDDの開発思想部分の全てが入ってる感じだった

アーキテクチャとかその後のプラクティスはそれをコードで表現する表現手法にすぎない

全人類にこの3章だけでも読んで欲しい章

7章 言語を使用する : 応用例

実際にドメインモデリングを導入する感覚を掴める章で 1 ~ 6章 を読んだあとに一通り自分のサービスとかで実践してみると結構学ぶものがありそう

ドメインを隔離する : アプリケーションの導入

Entity と Value Object を区別する

ドメイン関連を設計する

集約の境界を定める

リポジトリを選択する

8章 ブレークスルー

いつも自分は「ドメインの発見」とか「知識の獲得」とか呼んでる部分の話だった

実際にこういう自分が何を作ってるのかがはっきりする場面は結構あるのでブレークスルーみたいなたまにしか起きない表現じゃない呼ばれ方がしたかった

感想

DDDは、以下で構成されててそれぞれの概念的なところで整理された

開発思想

ドメインを揃えていく必要がある。ドメインエキスパートとの対話が大事

戦略的設計

ドメインモデルをうまく継続性を持たせるための設計 (境界づけられたコンテキストとか共有カーネルとか)

戦術的設計

ドメインを表現するための表現 (集約の抽象化としてのRepositoryパターンなど)

レガシーなシステムを作る上でも

ドメインが何か

境界づけられたコンテキストと共有カーネルは何か

あたりはとても参考になる考えであった