続・MVCのMのクラス設計草案など

もう、そんなに書く事も浮かばないんですけどね。

とりあえず、「何でもかんでも自作でやろうとしないで、利用出来るものは利用した方が良い」と思いますね。

既存のフレームワークやらライブラリやらを使って、車輪の再発明するなと。

というのも、業務で書くにあたって↑のコードを書くのは、

業務ロジックはゼロですし、完全に無駄な時間なわけで。

勿論、既存のフレームワークやライブラリで対応出来なかったり、

業務要件的に必要だったり、その他の事情でフレームワークを導入出来ないとかなら、

書く必要はあるわけですけどね。

っていう事と、現存のPHP フレームワークで、デフォルトでDDDの構造になっているものが・・・ありますかね？

って所を考えると、現存のフレームワークのクラス構造じゃダメなのか？という。

実際、DDDの案件の時は、Cakeでしたけどフレームワークの機能は殆ど使わず（モデル以外は使える）自作でしたからね。

なので、その部分はロスなわけですが、そのロスを取り返せるのかどうか（勿論、取り返せるなら良い）と。

・・・以下の、「覆水盆に返らず」みたいですね。勿論、グダグダ設計のグローバルは、言うまでもないとして。

あと、これは↑とは別の現場ですが、そこでのDDDでは、

「Modelというクラス名なのに、フィールドに対するgetterとsetter（こっちは無かったかも）しか無かった」

という、なんじゃこりゃ？感（これはエンティティでは？）なケースもあり、

「用語が指している意味がバラバラ」かもとは思いましたね。

ただ、その現場は、資料で詳しく解説があったので、

「あぁ、そういう意味で使ってるのね」とは思ったので、特に問題無いかとは思いましたけど。

これは、DDDの原理原則からは外れているのかもしれないですが、

原理原則の形で「しか」使えないなら、柔軟性には欠けるかなぁと。

だから、前回のリンクにもありましたが、以下のやり方もアリだと思いますし。

別件だと、MVCで「コントローラークラスは１つ or 複数？」論争とか、

以下の様な、「どっちに書く？」系とか、最近は気にしなくなったかなと。

あとは、DDDの時に思ったのが、「１クラスの担当責務」にうるさいので、

Utilクラスが無かったり、Constantが超細分化（これ自体は良いと思うが、ちゃんと構成を考える必要がある）したりと。

それに拘ったからですかね、色々なクラスに「private const NEW_LINE = "\r\n"」みたいなコードがあったのは。

いや、PHP_EOLじゃダメなんですか？って感じなんですけど。

Utilとか、色々なクラスで使うのに、何故Utilに書かない？ってのは、

「縦割り」というか、横を意識しなかったのかなと。

更に・・・まぁ、良いわ。せめて今回僕が↑に書いたコードぐらいには、

共通化はして欲しい（fetch()とか、やろうと思えば、まだ出来るけど）とは思いましたね。

まとめる（というか、前回のに追加する）と、プロジェクト的（要件・メンバー構成・期間・予算）に、

どの方法が最適解か、よ～く検討するって所でしょうか。

DDDは、本を見ても「対象範囲がかなり広い」ので、

気を付けて導入しないとハイリスク・ローリターンになると思いますのでね。

あと、本日のBGMは、B'zの「弱い男」 http://j-lyric.net/artist/a00067d/l043c9d.html でした。

いや、こういう微妙な話は、自分一人では決めれない弱い男なので（笑）