2/4-5のリアクティブな話

pokarim @pokarim

手続き的になるから嫌なだけではなく、スキーマやロジックを変更する際のコストがどうしても大きくなるのが特に嫌。

pokarim @pokarim

あれが嫌これが嫌とか言ってると駄々こねてるみたいだな。実際駄々こねてるんだけど。

Mamoru Iwasaki @mamoru125

@marblejenka 専用(単独)アプリだとするとオブジェクト(エンティティ)ベースのがやりやすくて、汎用的にするとなるとリレーショナル。でも、僕の先入観かもしれないです。

pokarim @pokarim

あまり問題視されていないけれど問題だと思うのは、データの置き場とどんなデータが入りうるかを決める場所が離れている事。

marble @marblejenka

@pokarim 手続き的に書くとなんか困ります？ってのは正直あります。単項目／相関できっちり整合性がとれれば要件的にはokのはずで。この辺のルールの実装で関数型とか、そっち系のパラダイムがでてくる余地ってあります？

marble @marblejenka

@mamoru125 モデリングの観点？だとあまり関係ないかなと思います。手段が違うだけなので。ビジネスルールを実現するにあたって、複数アプリで1DBを見るなら、DBでルールを実現するのがいいのかなというくらいの話であるという理解です。

pokarim @pokarim

@marblejenka とくに困っているという認識は誰ももっていないと思います。ただDBMSを含めてリアクティブに記述できるとめちゃくちゃすっきりできるというのが見えてきたので、それと比べてどうしても歯がゆく見えます。

pokarim @pokarim

@marblejenka 具体的には、手続き的だから問題なだけではなく、スキーマとロジックが分離している事が、仕様変更時のコストを増大させていると見ています。

pokarim @pokarim

@marblejenka 今の説明では説得力が無いのは自覚してます。議論としては成り立ってないのですが、ただ、誰も困っていなくても、DBMSとアプリを切り分けることが前提になっていて他の選択肢が視界に入ってないだけなように自分からは見えるんです。

pokarim @pokarim

手続き的で困っていないと言われても、何が何でも宣言的に書き直さないと気が済まないというただのわがまま。

marble @marblejenka

@pokarim さんの見えてる世界が理解できてない感もあるのですが、DDDとかだといわゆるドメインオブジェクトはモデリングしますし、ドメインをまたぐものはサービスとして抽出しますし、それほど抜けもない気もしています。リアクティブの威力がどれほどか、という話もありますが。。

pokarim @pokarim

@marblejenka いつも使っている例ですが、入庫の度に在庫をインクリメントするのが本質的なロジックだと言われるとそれまでなんですが、入庫数の合計から出庫数の合計を引いたものが在庫数でありそれは0以上であると書ければ、記述量は圧倒的に減らせると思うんです。

pokarim @pokarim

@marblejenka もちろんひとつの具体例を持ってきても一般的な結論にはならないのでそこが自分の議論の限界です。ですが、たとえば倉庫毎、商品種別ごとの在庫数に加え、訂正処理が入った場合、その差はどんどん顕著になると思うんです。

pokarim @pokarim

@marblejenka 直接の返答になっていませんでしたが、DDDでもイベントの伝播はそもそも手続き的なものとして記述されると思います。そこがなぜ問題かを説明したいのにうまくできないのが現状なんですが。

marble @marblejenka

@pokarim なるほど、だいぶわかりました。けっこう前のあれですね。言葉としては微妙ですが、ルールベースとかそんな感じですかね。うーん。例えば、あるものの原価を買ったときの値段とする方式（いわゆる個別原価法）だと、それほど有効でない気もします。とはいえ効果的なケースも、という

marble @marblejenka

@pokarim や、記述としては手続き型自体がびみょいと思います。ものによると思いますが、数式として表現されるビジネスルールは結構多いはずなので。見た目的には、宣言的なほうが合いやすいと思います。ある時点のとか、制約条件がついたときに書きやすいかどうかというのはありそうですが。

pokarim @pokarim

@marblejenka そうですね、一度計算して出た値がそのまま事実として記録されて不変な場合はあまり差は出ないと思います。差が出るのは一カ所の変更が他に連鎖的に影響を及ぼすような場合です。あとバッチ処理中心だとこの部分は見えにくいというのがあると思います。

pokarim @pokarim

@marblejenka そうです。まさにそんな感じです。＞数式として表現されるビジネスルールは結構多いはずなので。見た目的には、宣言的なほうが合いやすいと思います。

pokarim @pokarim

プログラマは一般的に手続き的な思考に慣れているので手続き的な記述は簡単、宣言的な記述は高等なものと思いがちだが、Excelの使われかたを見ていると手続き的な記述の方が実は難しいのだと思えてくる。

Mamoru Iwasaki @mamoru125

@marblejenka アプリケーションモデルからはそうですね。インフラで、どこまで見るかなんだと思います。インフラ意識すると今の開発スピードの足は引っ張るかもですね。

tomo🐧@learning @cocoatomo

@pokarim @marblejenka データ長も DB と画面 (Web でもローカルでも) で2重持ちになりがちですよね.

tomo🐧@learning @cocoatomo

おはようございます.

pokarim @pokarim

@cocoatomo おはです。

tomo🐧@learning @cocoatomo

@pokarim なんだか昨晩の議論が熱いですね. 今追ってるところです.

pokarim @pokarim

@cocoatomo @marblejenka そういうのもありますね。とりあえず現状の解決策は一カ所の定義から他の場所の定義を自動生成することだと思うんですが、自動生成ソリューションは例えば変更に弱くていまいちだなと思ってます。