Open YuheiNakasaka opened 2 years ago
Web Development with Ruby on Railsを読んでる。
modelにロジックは書かない、1コントローラーメソッドに対して1Serviceにしてそこに必要なビジネスロジックは詰めこむ、serviceは1メソッドしかpublicにしない、serviceのpublicなメソッドの振る舞いのみ入念にテストするという割り切った考えは前評判どおりだけど思想強ぇ〜となった。
RailsでDDDとかやろうとするとドメインの整理から始まりmodelはただのDTOにしてentityやvalue object等の実装を用意して、なんというか少なくとも実装に関してはクラスがめちゃくちゃ増えていくイメージだけど著者はむしろそういうのと逆方向(というかRailsとしては自然な方向)に逆らわず標準提供されてる道具を使って、最低限のレイヤーをサステナブルという目的(ここが重要)を達成するためだけに追加するという考えだ。
設計に絶対的な正解はなく、未来・要件・チーム・言語・フレームワークなどにあらゆる環境によって最適な選択は変わるという当たり前のことを思い知らされる感じ。
良いコード／悪いコードで学ぶ設計入門を読んだあとなのでなおのことその実装方針の差が面白く感じた。
良いコード設計ができるというのはこういった多種多様な設計方針や実装方法の引き出しがあり、その中から妥当なものを選択できる能力なのだろうと思う。(もっと広い意味でだけど)アーキテクチャ選択に絶対はないというのはソフトウェアアーキテクチャの基礎でも書いてあった気がする。
自分は金にならんプロジェクト(スタートアップのすぐ解散するアプリ開発や少人数開発みたいなもの)ばかりやってきたから将来性についてあまり深く考えなくてもぶっちゃけよくて、そんなに神経質に設計について固執してこなかった。そのツケみたいなもので設計に関するスキルにややコンプレックスがあるから最近はこういう本をいくつか読んで妄想したりしている。
自分のようなバックグラウンドの人間からするとどんなにクソコードでも金を産むコードに対してまずはリスペクトが生まれてしまうという悲しい性。めくじらたててキレ散らかしてる人を見るとなんともいえない感情にならん訳でもない。もちろんそれとこれとは別なのは理解するが....
Web Development with Ruby on Railsを読んでる。
modelにロジックは書かない、1コントローラーメソッドに対して1Serviceにしてそこに必要なビジネスロジックは詰めこむ、serviceは1メソッドしかpublicにしない、serviceのpublicなメソッドの振る舞いのみ入念にテストするという割り切った考えは前評判どおりだけど思想強ぇ〜となった。
RailsでDDDとかやろうとするとドメインの整理から始まりmodelはただのDTOにしてentityやvalue object等の実装を用意して、なんというか少なくとも実装に関してはクラスがめちゃくちゃ増えていくイメージだけど著者はむしろそういうのと逆方向(というかRailsとしては自然な方向)に逆らわず標準提供されてる道具を使って、最低限のレイヤーをサステナブルという目的(ここが重要)を達成するためだけに追加するという考えだ。
設計に絶対的な正解はなく、未来・要件・チーム・言語・フレームワークなどにあらゆる環境によって最適な選択は変わるという当たり前のことを思い知らされる感じ。
良いコード／悪いコードで学ぶ設計入門を読んだあとなのでなおのことその実装方針の差が面白く感じた。
良いコード設計ができるというのはこういった多種多様な設計方針や実装方法の引き出しがあり、その中から妥当なものを選択できる能力なのだろうと思う。(もっと広い意味でだけど)アーキテクチャ選択に絶対はないというのはソフトウェアアーキテクチャの基礎でも書いてあった気がする。
自分は金にならんプロジェクト(スタートアップのすぐ解散するアプリ開発や少人数開発みたいなもの)ばかりやってきたから将来性についてあまり深く考えなくてもぶっちゃけよくて、そんなに神経質に設計について固執してこなかった。そのツケみたいなもので設計に関するスキルにややコンプレックスがあるから最近はこういう本をいくつか読んで妄想したりしている。
自分のようなバックグラウンドの人間からするとどんなにクソコードでも金を産むコードに対してまずはリスペクトが生まれてしまうという悲しい性。めくじらたててキレ散らかしてる人を見るとなんともいえない感情にならん訳でもない。もちろんそれとこれとは別なのは理解するが....