DDDとかクリーンアーキテクチャは寿命を言語 > アプリ = アーキテクチャ >>> フレームワークと考えている節があって、実際にはデータ >>>> データベース >> OS > 言語 > フレームワーク >>>> アプリという世界もある。データベースに魂を込めてモデリングする、アプリはおまけという思想も根強い
DDDとクリーンアーキテクチャに批判的な人の大部分は、ソフトウェアの本質はUI(機能とUIは不可分)だと思っていて、なんでもUIドリブンで作るべきで、バックエンドは可能な限り何も考えず、できれば自動生成したいと思ってる
賛同する人はソフトウェアの本質はUIに依存しない機能だと考えてる
https://twitter.com/cactaceae/status/1726347254540513503
@cactaceae
@shibu_jp
gRPCとかREST APIなんかよりも、DBでどかっとデータ流し込みとか、ファイルでどかっと流し込みとかHULFTだぜ！とか全銀プロトコルとか流通BMSみたいな世界。
@shibu_jp
実のところ、クリーンアーキテクチャが想定するような「フレームワークの変更の影響を受ける」って事象はどれだけリアルなんだろうか？Rails、Django、Laravelとかそろそろ20年とか15年近いよな。J2EEも仕様があってフレームワークがある、という思想であるし。
@shibu_jp
MEMO:
- クリーンアーキテクチャがデータを軽視しているかと言えば別にそんな事はなく、単にフォーカスする問題（アプリケーションアーキテクチャ）が違うのでそう見えるだけでは？ と感じる
- 一方で、エリック・エヴァンスのドメイン駆動設計におけるデータ設計はお粗末なものもあったから、もしかしたら軽視してるのかもしれんわ確信がないわ（以下略
- なお、自分もドメインモデルを考えるよりもデータモデル（テーブル設計）を先に考えた方がよいという価値観である
- バッチでドカッとデータをDBに流し込まれるのがメインでアプリはおまけという世界観〜は、そういうのもあるし、そうでないものもあるという話でしかない
- 「フレームワークの影響を受ける」はシステム開発やってればそれなりにリアルに体験することだと思うのだが
- Javaの世界だけでもStrutsから脱却できなくて脆弱性晒した企業がいくつもあったことを覚えていないのだろうか？
- フレームワークに依存し過ぎていて引き剥がすことができず、やるなら全面的に作り直しになる→そんな金無い→マゴマゴしている内に脆弱性発覚→無事死亡という流れ
- PHPならCakePHP全盛期の頃に作られたシステムを抱えた企業がPHPフレームワークの覇権をLaravelに席巻されてしまい、開発者の確保に苦労するとか
- 勿論、金と時間を掛ければ解決する問題ではあるのだが、せめてドメイン層がフレームワークから独立していればもう少し低コストに別のフレームワークに移行できたという事は多いだろう
- とはいえ、クリーンアーキテクチャを全面的に採用するのはメリットよりもデメリットの方が多いと思っていて、無邪気にクリーンアーキテクチャを振り回す人にはどうしたもんかなぁと思うところはある
(2023/11/21)