奇特なブログ

「殊勝に値する行いや心掛け」を意味する、奇特な人になる為のブログです

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

前回記事:
MVCのMのクラス設計草案など - 奇特なブログ

前回の草案ソースとの差分(ちょっと多過ぎますが):
モデルクラスの設計草案を作成(一旦完成) · kitoku-magic/other@f89baf7 · GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

覆水は盆に返せるのか? 余談 - gallu’s blog



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

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

という、なんじゃこりゃ?感(これはエンティティでは?)なケースもあり、

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

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

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

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

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

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

PHP Mentors -> ドメイン駆動設計のリポジトリパターンをプロジェクトへ持ち込む時の話

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

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

Model、どうすっかねぇ? 的な - gallu’s blog



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

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 でした。

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