DDD（とClean Architecture）

ハーイ。Fです。

職が変わり、コロナで外に出づらいのもあって、コツコツ勉強してました。

そんな勉強のメモを連投しておきたいと思います。

今回は以下を読んで参考になったところの抜粋です。

Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 (infoq.com)

DDD（ドメイン駆動設計）が含むもの

DDDは、以下の２点からなる。

１．開発をより良く進めていくための、ビジネスの専門家との対話、進め方のルール

２．それを実現するためのソフトの設計手法（レイヤーアーキテクチャー）

２に、後述するユビキタス言語などが属する。

対話のためのメソッドと、設計のためのメソッドで章を分けてみました。が、元の本では特に区別されていないので、ここはFなりの理解になります。

また、正直元の本の章立て的に綺麗に分けづらいところはありました。あくまで大まかな目安としてください。

Clean Architectureとの関係

CleanArchitectureは、１をさらに良くするための設計手法。

ベースとなる考え方はDDDを踏襲している。

考え方

ソフトは、何かを解決するために作成する。その「何か」＝業務というをドメインとし、ドメインを軸に開発する。（話を進める）

業務に詳しい人（専門家）から、ドメイン知識を教えてもらう

専門家は、ソフトには詳しくない

　何を教えればソフト開発が進むか解っていない

　開発者と専門家で意見を交換し、理解を深めていく

これに対し、開発者はドメインモデルを作り上げ、ドメインモデルに対してソフト設計を進めていく

専門家と開発者間で、知識の乖離を小さくすることで、開発されたコードと業務を近づける。従来は、ここが離れてしまい、業務のアップデートに合わせた、ソフトの更新時に困るなどの弊害が出やすい。

対話のためのメソッドとツール

ユビキタス言語（２章）

開発者と専門家で齟齬をなくすための共通の言語。

この言葉をモデリングにも使うことでモデリングも容易になる。

設計におけるメソッド

モデル駆動設計（３章）

ドメインモデル（ドメインを表したモデル）を如何にソースに落とし込むかが重要

　ドメインとソースのモデルに乖離があると、今後の変更が複雑

　ドメインを表したソースにならなくなる

　分析モデルが推奨される手法

　　多くの場合、コード設計者とは別の人が業務モデルを作成する（分析する）

　　しかし、、乖離が起きやすい

　　→ドメインモデリングと設計を密接にすべき。開発者も業務モデリングに参加すべき

レイヤーアーキテクチャ

プレゼンテーション/アプリケーション/ドメイン/インフラストラクチャー

に分割する（クリーンアーキテクチャの元）

エンティティ/値オブジェクト→ドメインオブジェクト

　ドメイン知識を表すデータ

　エンティティはIDを持ち、一意に特定できるデータ

　全てをID管理するとコストがかかるので、そうしないのが値オブジェクト

　　クリーンアーキテクチャによるEntityとは微妙に異なるので注意

モジュール

一般的な話

アグリゲート（集約）

ドメインオブジェクトのアクセスを切り分ける

ルート同士のみアクセスを許容する

ファクトリ

ドメインオブジェクトの生成に関するテクニック

GoFの手法に近いが、ドメインオブジェクト生成に特化する

→リポジトリパターン

　DBなどへのアクセスはリポジトリが担う

リファクタリング（４章）

リファクタリングを行う際に、ドメインに対し、さらに深い洞察を行う

ただし、ドメインの概念の変更が激しく行われた場合、コードの修正は膨大

→柔軟な設計が必要

モデルの完全性の維持（５章）

巨大なプロジェクトにおけるDDDの実践方法

巨大なプロジェクトでは、すべてのモデルを全員が正しく認識し、実行し続けることは困難

モデルを小さく分割し、コンテキスト境界を定義する

モデルは、１つのチームに割り当てられるぐらいのサイズにする

分割したモデルごとに、モデルを維持する

コンテキストマップ

コンテキスト境界、関係を示す図

共有カーネル

境界が重なる箇所、この箇所の実装に手を入れる場合には要注意

感想

DDDの考え方としては「ちゃんと作るものを理解してコードに反映しようよ」という、ある意味当たり前とも思えるものでした。

ただ、経験的にもやってみると意外と難しく、それを方法論まで含め開発手法を定義しているという点で非常に良いと思いました。

方法論の内容も共感できるものだったので、良い点を取り入れていこうと思います。

自分のメモの書き写しみたいな記事ですが、このテのやつ何個か連投します。。。ではまた。