アーキテクチャパターンについて調べてみた
今日のスタートになった記事
Controllerは薄く書けとのことをひたすら読んだので実践したところ、ModelがFatになったり持っている機能の範囲が広くなりすぎたりするのが不満だったのと、2つ以上のModelにまたがった機能を実装するときその機能はどのModelの責任になるのかみたいな疑問に対してどんぴしゃでした。
これ読む前に自分でもアプリのユーザー体験に基づいた機能(ドメインロジックって呼ぶんでしょうか)を切り出して別クラスを作って、ModelをDBアクセスのためだけに使おうとかしてたんですが、なかなかうまく作れなかった。
その中で紹介されていた記事
実際に自分が陥っている問題の具体化だとか、対策としてどういうものがあるかなどがはっきり書いてあったのでよかった(SQLアンチパターン読まなきゃな)。あと自分が作ろうとしていたものがサービス層というものだということ(全ッ然違うけど)が分かっていろいろ調べられるようになったし、DDDって聞いたことあったけどそういうことだったのね、とか。DDDの本やばそうですね。DCIってなんぞ。。。レイヤーアーキテクチャっての面白そうだな。
やっていこうとは思うけど、ここに書いてあることをやってそれが本質的な問題解決につながるようになるには経験もスキルも足りなさすぎるなぁという感じ。
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
上の記事のスライドの中で出てきた「ドメインモデル貧血症」の話。
ビジネスロジックはあくまでドメインに記述すべきもので、アプリケーション層なんかはそこにタスクを投げるだけにするという意味でControllerは薄く書くものだという意味だったんだなと理解。
railsとかのどうでもよいメモ: DCI (data context interaction)
DCIってなんぞってわけで読んだ。
DCIとは全く関係ないんですが
そういう意味で、例えばデザインパターンのような技術者だけの道具が設計の初期に出てくるのはおかしい。技術者はえてしてそういう技術話が好きなものだが、ラムダとかデザインパターンとかmix-inとか、ビジネスロジックの出てこない道具は「syntax上」の道具でしかなく、これはつまり局所最適化にしかなりえない。それを全体レベルの最適化に使ってもうまくいくはずがない。こういう道具は局所戦でしか使ってはいけない。
ってところ、その通りだと思います。肝に命じておきます。
でDCIについてはここにはあまり書いてなかったので
を読みました。軽めの内容で読みやすかったです。
実際にこれ実践できると、Roleなどに応じてコードをどんどん分割できて綺麗に管理できそうですね。でもDCIってのは僕の求めている類の対策というよりは開発手法なのかな。今から急に採用してってことはできなさそうです。もし今度もっと使うのであれば勉強しないといけないですけど、今はDDDの方に興味があります。
サービスを作るときの責任の持たせ方の参考になりました(OOが分かってない顔)。
上の記事と合わせて責任の分け目ってこういうところに作るんだなって。
アプリケーションのレイヤー化についてよく分かってなかったので自分で読みやすいものを探してきた。
ドメイン層だけじゃなくてアプリケーション層なども合わせて読んで理解が深まりました。依存関係のところとかしっかり守ってカプセル化とかうまくやっていきたいです。
でもこれこのJavaのフレームワークの思想はこうですよっていう内容だしDDD原本はまだ怖いので
https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html
の内容なんかを時間があるとき読もうと思います。
あんまりかいつまんだ勉強をしてもなんだか正しい理解なのか不安になりますね。。とりあえず自分で実践していくときは読んだ内容はあくまで参考としていくということにします。
アプリケーションっていうのは問題解決のためのものであり、コードはその解決のある部分を担うという意図を持って書かれている。コードはアプリの機能のロジックを実現するものであったり、他のコードからツールとしてだけ使われるものだったりする。そのような性質によってコードの置かれるべき階層などに分けて、コードの再利用やコード同士の疎結合を実現しようとしている。
ということだけ頭においておきます。
こんな理解であってるんでしょうか。