クリーンアーキテクチャやらDDDはどこまでやるのがちょうど良いと感じるのか
shimakaze_soft
こちらの記事を読んでいて、感じたことをメモしていく内容。上記リンクの記事の内容はタイトルと違ってDDDに対するポエムな内容。(Qiitaらしい記事）
結論から言うと、記事の内容は「無目的なデザインパターンの乱用が発生」や「ドメインを失ったDDD のデザインパターンだけを利用しようとしているのは危険」とのこと。
箇条書きでまとめる
- オブジェクト指向が良い設計のすべてと信じられていた
- GoFのデザインパターンは教育面で失敗し、無目的なデザインパターンの乱用が起こった
- DDDが再燃し、コードと業務を一致させる組織論を諦めて、軽量DDDが提案されるも危険な思想
- DDDのデザインパターンはユビキタス言語形成の道具
- DDDのデザインパターンだけ真似すると効果が薄れ、開発が遅くなる
- オブジェクト指向の本来の意味と良い設計について再考が必要
- 自分の設計センス (= いろいろ見てきた経験) に従ったり、他人のコードを読んでいるうちに、そこにパターンを見出せるようになっていく
shimakaze_softドメイン駆動設計を行うとは言わない方が良いのではないかと考える。
上記の記事では、本質的なドメイン知識をコードに結びつけるという目的のためにやらなければむしろ大変になると言う意味でもある。
あくまでもクリーンアーキテクチャライクな実装をするという言い方や考えたが良いのではないか。
ドメイン駆動設計を実践する際に、軽量DDDと称して戦術的設計やデザインパターンだけを全て適用しようとすることは、ビジネス的な本質を見失う恐れがある。
ビジネス的な本質を理解して、適切に反映させるためには戦略的設計などの全体的なアプローチが不可欠になる。
一方で、全てとは言わずとも、一部のデザインパターンを適用することで、コードの肥大化を防ぐことができる。
サービス層などと呼ばれるビジネスロジックを実装する場所を設ける、リポジトリパターンぐらいは導入しやすいのではないかと考えている。
- サービス層
- リポジトリパターン
例えば、MVCフレームワークなどを採用して開発をしている場合、ControllerとModelのどちらかにコードが肥大化(FatModel, FatController)していきがちな傾向があり、それを避けるためにもビジネスロジックを扱う別の層を設けることも良いのではないかと考える。
これにより、「Controllerに全て書く」よりはコードの構造がより整理され、保守性や拡張性が向上する。
ただし、サービス層というものを設けることにも疑問を感じている人の記事もある。
内容を読む限りは、「オブジェクト指向の原則に従って設計すること」て書いてあることについてはわかる。個人的にもSOLID原則などもかなり大事だとは思っている。
ただし、RubyやRailsで開発していて起こりがちなことについてだったり、少し極端でもあるのかなと感じることもある。ControllerやModelがFatになっていくぐらいだったら、まだディレクトリなどを切ってサービス層みたいなものを設けた方がマシなのかなと個人的に思うこともある。
スタートアップ企業のような所ほど、仮説検証をしていなかないと考えると、設計をどこまでやるかをどこかで割り切りはすごく重要になってくる。
以下の記事みたいに継続して少しずつ実践していけるような形が一番優しくてわかりやすいのかなと思っている。
こちらの章では、ドメイン駆動設計ではないですよと述べているし、「Controllerに全部書く」から少しずつ脱却していくようなことを全体的に目指している。
こちらの章でもRailsなどに出てくるActiveRecordなどの扱いについても触れている。
それでも一番に重要なのは、デザインパターンやアーキテクチャを適切に選択し、ビジネス要件に適した形で実装すること。ビジネス的なことを一番に優先して考える。
shimakaze_soft以下のデザインパターンぐらいはリポジトリパターンとして使用することは考えても良いのではないかと考える。
- AbstractFactory
- Facade
後はもし、少しずつクリーンアーキテクチャを実施して苦なら以下のデザインパターンは参考になる？
Adapterパターン
層：インフラストラクチャ層
説明：外部システムやライブラリとの互換性を保つために、Adapterパターンを使用して、アプリケーション内部のインターフェースと外部システムのインターフェースを変換します。
Factoryパターン
層：ドメイン層、アプリケーション層
説明：オブジェクトの生成をカプセル化し、クライアントが具体的なクラスに依存しないようにするために、Factoryパターンが使用されます。
Repositoryパターン
層：インフラストラクチャ層
説明：データストアへのアクセスを抽象化し、データストアの具体的な実装からドメイン層を独立させるために、Repositoryパターンが使用されます。
Strategyパターン
層：ドメイン層、アプリケーション層
説明：異なるアルゴリズムや戦略を実行時に交換可能にするために、Strategyパターンが使用されます。
Observerパターン
層：ドメイン層、アプリケーション層
説明：状態の変化を検知し、関連するオブジェクトに通知するために、Observerパターンが使用されます。
Facadeパターン
層：インフラストラクチャ層、アプリケーション層
説明：外部システムやサービスの複雑さを隠蔽し、シンプルなインターフェースを提供するために、Facadeパターンが使用されます。
Singletonパターン
層：インフラストラクチャ層、アプリケーション層
説明：アプリケーション全体で共有されるリソースやサービスのインスタンスを制御するために、Singletonパターンが使用されることがあります。
shimakaze_soft参考になるGitHubのサンプルソースコード