創作物（ドラマやアニメ）において、「この物語はフィクションです。登場する人物・団体・名称等は架空であり、実在のものとは関係ありません。」という注意書きが必ず記載されるのと同様に、個人ブログにおいても、必ず「この記事は個人の見解であり、所属する組織の公式見解ではありません」という但し書きを書く必要が出てきたので、鬱陶しいですが毎回書きます。ご容赦を。
「この記事は個人の見解であり、所属する組織の公式見解ではありません」
私は、例えばRuby on Rails のような強力なwebフレームワークが非常に苦手で、なんでこんなにやりづらいんだろう？と思っていた。フレームワークを入れたは良いが、実現したいソフトウェアをいざ実装するぞとなったら、まるで手が動かなくなる事が多い。その原因がさっぱり見えていなかったのだがようやく分かってきたので書く。
1. そもそもちゃんとドメインモデルを構築できていない。
フレームワークどうこういう以前の問題として、私個人のモデル設計力が低い。 とにかくコレに尽きると思う。特に学生の時は深いことをさっぱり考えずに「とりあえず実装するか」とコードをしっちゃかめっちゃかに書きなぐって「とりあえず動いたからリリースしようぜ」というのが許された。（許されたわけではないと思うが、基本的に設計から実装からリリースまで全部１人だったし、趣味の園長のようなプロダクトなので、困るのは自分くらいだった）
なので、オブジェクト間の依存関係とか全然考慮されておらず（いや、多少は考慮していたが、完成度の低いモデルで）酷い設計/実装だった
2. フレームワークの学習コストの見積もりが甘い
Zendにせよ、RoR にせよ、Django にせよ、所謂「重い」と言われるフレームワークはとにかく、何人もの優秀な技術者の知恵と努力が何年も積み重なったもので、一介の素人がちょっとドキュメントを読んだだけで理解出来るものではない。（ちょっとドキュメントを読んだだけで全てが分かるのなら、世界は優秀な技術者を必要としない）
とにかく学習コストが高い。学習コストが高いと嘆いているうちは、まだ自分の道具になっていないという事だし、道具に振り回されて疲れ果てることになる。既に道具として使いこなしている先輩方から「これはこうしたほうがいいんじゃね？」と言われても、何を言われているのかわからないので、反論が出来ない。
また、上述の通り、ドメインモデルがしっかりしていないので、「このフレームワークではこうするんだ」というフレームワークの思想が優位に立ち、本当にすべき実装が見えていない。というのもある。
という事を青DDD, 赤DDDを読みながら思った。
青DDD は読むの物凄くしんどかった。オススメしない。赤DDD は DDD についてある程度知識がある前提で進むので、青DDD の要約スライドを見て挑むのが一番学習効率が良さそう。
