投稿日: 2022-05-22
仕事で最初に関わったプロジェクトはDDDの実装パターンを採用していたのですが、当時はなぜそのやり方をするのかが分からずモヤモヤしながら開発していました。
コードを書いているうちに、実装パターンが抱える課題とそれを解決する方法が分かるようになってきました。そして、「MVCから他のアーキテクチャは課題とその解決策でつながっている」と理解できたので、当時の自分に向けて書こうと思います。
アーキテクチャについて考えるときに重要なのは、自分で手を動かして課題を体感して、それを解決するための手段を探していくことだと思っています。
なぜそれが重要かというと、考え方が分かっていなければ正しく使うことができないからです。いきなり高度なアーキテクチャを取り入れたとして、課題や選択に直面したときに、背景にある考え方を知らずに適切な選択肢をとれるでしょうか?
課題ベースで手段を探すことは、このミスを防ぐことにつながります。なぜならその手段を取り入れる理由や目的がはっきりしているからです。
ドメイン駆動設計についてきちんと学んだことはないので正確な認識ではないと思いますが、現時点での私のDDDに対する認識は以下のような感じです。
各実装パターンと、その実装パターンの課題を解決するとどの実装パターンになるかを図にまとめてみました。
ざっくり説明すると、①のMVCから始まり、システムの登場人物(エンティティ、ドメインモデル)の扱い方で②と③に分かれ、④で合流し、その先にバリエーションがある感じです。
各実装パターンの特徴を書きます。
実装パターン | 特徴 |
---|---|
①MVC | システムに登場する人やモノとDBのテーブルを対応させて、開発スピードを高める |
②MVC+ユースケース | モデルの肥大化を防ぐために、ユースケースに処理を書く |
③リポジトリパターン | 業務ロジックとデータ操作の処理を分離する |
④リポジトリパターン+ユースケース | 業務ロジックと業務を実現する手続きを、それぞれ適切なクラスに配置する |
⑤Flyweight DDD | 書き込みはリポジトリパターンを使ったSimpleな実装、読み取りはフレームワークを使ったEasyな実装にする |
⑥進化系? | オニオンアーキテクチャ、ヘキサゴナルアーキテクチャ、クリーンアーキテクチャなど |
今業務で作っているシステムは、Flyweight DDDを参考にして作っています。目の前の課題を解決していった結果ここにたどりつき、今作っているシステムの複雑さに対して適切な選択(オーバースペックでもアンダースペックでもない)だと考えているからです。
ただ、マスタなどはリポジトリパターンを採用するのは大げさなので、MVCを使っています。複雑さに合わせて、適切な実装を選択するようにしています。