2014 年最初のブログです > Ruby/Rails 用 DI コンテナ Dee をつくった http://t.co/vABmwWB5A5
2014-01-01 01:29:48ちょっと釣りっぽいタイトルになおした > Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて http://t.co/vABmwWB5A5
2014-01-01 01:31:44なんで DCI がさらっと Dis られてるのかちょっとわからなかった / “Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて - Born Too Late” http://t.co/0lV9jfUb6A
2014-01-01 05:24:47@rosylilly もともと、ドメインロジックとか、DB 関係無いモデルをどこに書くか、というときに、いま流行の DCI とか使うといいのかなぁ、でもフツーに Service クラス書けばよくない? って思ったところが発端なので。間接的には同じ問題領域に触れると思います。
2014-01-01 11:38:02@rosylilly DCI は、実装レベルでいうと、それを支援するフレームワークに依存すると思いますけど、デファクトっぽいのを見つけられなかったので手を出すこともしてません。Dicer は Railtie や Generator まわりを参考にさせてもらいました。
2014-01-01 11:40:51@yuya_takeyama よくわからないのですが、 DCI は FW に依存するからダメで、 Service は FW に依存しないからよい、みたいな話なんですか?
2014-01-01 11:42:51@rosylilly それもひとつです。もっと単純に言うと「よりシンプルな方法で解決できるんならそっちでいいじゃん」ぐらいの感じです。開発規模とか開発者のカルチャーに依存して変わって来るものだと思いますし、どちらかが優れているとかは思ってないです。
2014-01-01 11:46:39@yuya_takeyama シンプルな方法で解決できればベターなのは同意するのですが、DI の有用性からなんで DCI や ActiveSupport::Concern に飛んだのかがわかってません
2014-01-01 11:49:39@rosylilly どれも Rails が用意した Model をはみ出る処理をどこに書くか、という点で関係して来ると思います。比較対象としては DI コンテナでなく Service の方がより厳密ではありますね。DI コンテナはあくまでもそれを支援するツールでしかないので。
2014-01-01 11:52:30@rosylilly @yuya_takeyama DIとserviceで十分に解決できる問題をなぜDIを否定した上でDCIを議論しているのか?という疑問だと感じた
2014-01-01 11:52:57@yuya_takeyama Model をはみ出る処理の具体例がいまいちわかってないのですが、 Service と DCI を比較するという話なんだったらわかります。
2014-01-01 11:56:37つまりちゃんと DI を使うことを検討して、やってみて、それでも無理なぐらいの規模になったので他を検討しますとかやるべきで、 DI を考慮にも入れずいきなり DCI やらを検討するのはおかしくね、って話なのね
2014-01-01 12:01:18DI 不要論の文脈と、DCI というのが凄いらしい、という文脈は全く別だと思ってるけど、DCI 不要論の人は結構「Service でよくね」って言ってたと思う。2013 年前半頃そういう人あちこちで見た覚えがある。
2014-01-01 12:01:20@rosylilly Model をはみ出る処理の具体例はこれもそうです。 http://t.co/fDPk0Ss1xz 複数の Model に横断していてどっちに書くか悩ましいから切り出してしまおう、みたいなものも含みます。あとは Web API に依存した処理とか。
2014-01-01 12:05:34@yuya_takeyama なるほどなるほど。確かにこれくらいの規模なら Service で十分というのはうなづけます。
2014-01-01 12:08:11DDDと同じように、DCIもモデリングとセットで語られないと意味はないだろうと思います。モデルと一致させることを目的としているのだから。単なる実装テクニックじゃない。DCIならばロールモデリングとは何を捉えることなのか?
2014-01-01 13:01:34DIというより、ServiceとDCIの話か。メンタルモデルとオブジェクト指向の関連性に重きを置いている、という話が見えないと、DCIの良さはわからないと思う。まぁDDDもそれと近い話ではある。
2014-01-01 16:17:34よりメンタルモデルに近づけて解決を図るアプローチと、実現する基盤となるソリューションの力を駆使して解決を図るアプローチ、本来この二つって一本化されている事がのぞましいんだけど、どうも亀裂がある感じ。
2014-01-01 18:51:40新年一発目のブログを書きました / 『DCI なんて面倒なだけで Service 使えばいい』への返答 - 鳩舎 http://t.co/FlkinMUsox
2014-01-02 10:49:50このロジックどこに書こう、って困ったことへの対処として作ったので、メンタルモデル云々は全然問題にしてない (あの記事だと)
2014-01-02 14:36:08とはいえメンタルモデルとかそういうのって大規模化してきたときに設計やる上で如実に差が出て来ると思うので、追々勉強していきたい
2014-01-02 14:38:31面倒だからServiceみたいなのはもう少し命名を考えて欲しいかなと思う。それは制約なの?仕様なの?ってなったら、もっと別の命名になるはず。名前としてServiceというSuffixを付けるべきものは本来もっと少ない。
2014-01-02 17:51:38Domain FacadeとしてのServiceとOperation ScriptとしてのServiceは、Enterpriseな観点だと同じ目的なんだけど、開発者が受け取る印象は全然違うので、ここらへんも着目する必要がある
2014-01-02 17:55:01