ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが？ - Qiita

ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが？LaravelDDD設計アーキテクチャCleanArchitecture ある日夢の中で設計に詳しい悪役令嬢が現れてこんなことを言い放ったので、考察してみましたという設定のポエムです。 問題提起 ドメイン駆動設計、オニオンアーキテクチャ、クリーンアーキテクチャといった考え方はもちろん重要なものの、僕は難しく考えずに「削除しやすいように機能を作る」のが第一歩として重要ではないかと考えています。 本記事では「削除しやすい設計」について持論を展開してみます。 ※議論のスコープはWebサービスに限定し、例示としてPHPのフレームワークであるLaravelを用います 削除しやすいことがなぜ重要か 一度開発した機能は、それで終わりではなく、改修、改善を繰り返し、そして場合によっては仕様が廃止さ

[versatile]

ご主人様なんて言い方は大正、昭和のもの。いまはプライマリ様

[EngineerYtr]

この考え方いい。修正対象のソースを読んだ後、絶対通らないロジックだと気付いた時の「ここまで費やした時間返せ」感はパないからな。

[sasasin_net]

「削除しやすい」は「疎結合」の一側面の最もわかりやすい言い換えですね。アプリケーションコードで例示されてますが、インフラ構成要素でも同じ議論ができそう

[turanukimaru]

これはトランザクションスクリプト、それも重複を一切躊躇しない、Webページ -> DB まっしぐらなやりかただな。sturts とか seaser2 では有効だった。今でも「初めての人」や「超単純なシステム」では一番わかりやすくはある

[tpircs]

小難しい色々を学んだうえで、それをそのまま実装するんじゃなくて、それを意識して現場のレベルや状況に合う設計をするもんだと思っている。そのまま適用するのは色々厳しい。

[i8858garden]

吊りタイトルだけど割と真っ当なことを書いたつもり。

[raydive]

削除しやすい設計というより削除しやすい実装といった印象

[n314]

削除しやすいようにするなら、SomeAwesomeディレクトリを作ってコントローラーもモデルも全部入れるかなあ。ファイルは層で分けて。削除は一瞬だし壊れる心配もない。共通処理が出てきたときに初めてModelとかDomainに書く

[teruyastar]

凝集、疎結合よりわかりやすい

[takatama]

あれれ？高凝集、低結合の話が出てこないぞ…。何のために、を学べていないから振り回されるんだな…

[burabura117]

一周回ってこれが新しい考えのようになっているの面白いなぁ…。ソフトウェアアーキテクチャの選択肢には他にも色々あるし、本来はビジネス、システム、組織の制約や特徴をもとに都度検討して決めるもんだけどね。

[at_yasu]

namespace は app/model/somesome,.. とかにしてたけど app/somesome/... のほうが変更範囲がわかりやすくて楽になった印象

[saiyu99sp]

簡単に削除できなくなるからアーキが必要なんだよ。

[otakumesi]

捨てやすい実装、ずっと考えてたことだ

[naglfar]

例はさておき、不要になった機能はきちんとコードからも削除すべきという方針には同意する。未使用とか廃止ってコメントをつけて残すくらいならバッサリしたい。

[programmablekinoko]

なるほど

[sashiharajp]

“削除しやすいように作ろう、と言う標語はかなり明確な指針”

[mimosafa]

“「削除しやすい設計」”

[for-my-internet-demo]

別にどれかの教義厳密にとらないまでも、落としどころチームが理解してるかは段違いだという感想だったので、最近の「いらないんじゃね」にこめられてる実装者のレベル感も相当にまちまちだと思ってる