TypeScript part4 (378ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
25(1): 2022/02/06(日)19:06 ID:AuLf6V7C(1/7) AAS
>>21
> Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
> 異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
> なのでドメイン層のクラスがJson Serializableである必要はない
横だがこれは完全に間違ってるだろ。
シリアライズするのは確かにI/O側だが、他言語も含めて今現在は
クラス側にserialize手段を用意するのが主流だ。TS知らんがJSと同じならtoJSON()。
だからドメイン側でシリアライズする可能性のあるクラスの全てにtoJSONを用意しておくのが正しい解だという事に今はなっている。
I/O側にやらせていたのは昔の設計だ。ただそれの何が悪かったのかは俺は知らない。
（実行効率だけは無茶苦茶良かったから、クラスを導入して非効率になっただけなのかもしれんが）
35(2): 2022/02/06(日)20:51 ID:AuLf6V7C(2/7) AAS
>>28
toJSONを呼ぶのはI/O層の仕事で、
toJSONを定義するのはドメイン層の仕事だよ。
つか、そうじゃないと無理なんだよ。
JSONでは対応出来ない型があるから、何が入っているか分からない状態ではシリアライズは出来ない。
逆に言えば何でもシリアライズ出来れば全部I/O側に任せる事は出来るのだが、
現時点で現実的にこれはバイトストリームしかないから、バイナリデータでメモリダンプ形式で良ければ出来るけど、
これはJSONともXMLとも言わないし、実際これをやってるシステムは今は無いでしょ。
37(3): 2022/02/06(日)21:14 ID:AuLf6V7C(3/7) AAS
>>36
まあそれでも出来るけど、それが面倒で二度手間で意味無いからみんなPODを使ってるんだと思うぞ。
FizzBuzzEnterpriseEditionとか、君は本気でやりそうだね。
外部ﾘﾝｸ:github.com
41: 2022/02/06(日)22:02 ID:AuLf6V7C(4/7) AAS
>>40
JavaScriptといえばJSON以外無い。
そしてXMLもDOMParserでどうにでもなる。
通信形式をドメイン側と分離するべきなのは「あらゆる形式に対応する」大前提でだ。
今時JSONかXMLしかないし、実際これで事足りるからみんなこれを使ってる。
密結合が駄目なのは「変更される可能性がある箇所」であって、何でもかんでも分離すればいいというものではない。
疎結合にすれば結局間接参照を中に挟むから、実行効率もコード効率も落ちるだけ。
Protocol Buffers見てみたが、ぶっちゃけこれ誰も使ってないだろ。
JSに対応してない時点で今現在のコンピューティングとかけ離れている。
現在もJSONで揺るぎないし、今後もJSONがさらに蔓延る雰囲気だ。
なら、ドメイン側がJSON形式に依存しても全く問題ないんだよ。
そこを無理矢理分離して、分離する意味の無いところも含めてあらゆる分離を行ってるのがFizzBuzzEnterpriseEdition。
君が言ってるのはこれ。
勿論、JSONが廃れればドメイン側のコードを書き換える必要が発生するけど、これは多分あり得ない未来なんだよ。
それでもこれに備えたければ備えるのも自由だけど.。
尚一応言っておくがJSONはJavaScriptObjectNotationの略で、つまりJSネイティブ形式だ。
だからPython等の他言語がJSON依存を避けるのならまだ分かるが、TS/JSで避ける意味はない。
君は完全にFizzBuzzEnterpriseEditionのノリでプログラミングをしてる。
48(1): 2022/02/06(日)22:57 ID:AuLf6V7C(5/7) AAS
>>44
まあ君とは平行線のようだね。
> 仮に変更される可能性がなければ１つの関数でシステムを組むのか？
組むぞ。俺は変更される可能性がない所に依存するのは全く問題ないと見てる。
そして基本的に実行効率重視だから、無駄な事はしない。
君はドメインが「１年が365日である事を知っている必要はない」として、365すらもリテラルでは書かないのだろう。
そして人類が火星に到達した時、君のコードは無修正で動くが、俺のコードは役に立たない。
でも俺は、「一方ロシアは鉛筆を使った」は大切にすべきだと思ってるから、
365はリテラルで書いてしまって、火星に到達してから書き直す事を選択する。
俺はJSONが廃れる未来なんてないと思ってるから、コードがJSON形式に依存するのも何ら問題を感じないし、
今のJSのアーキテクチャ、つまりtoJSONを整備しろ、で全く問題ないと思ってる。
これは確かに分離出来てないアーキテクチャだけど、する意味もないと思うよ。
むしろ他言語でもJSON使えないのはポンコツ扱いだろ今は。
> gRPC
> Message Pack
> fluentd
JSONがあまり効率のいい形式ではないのは事実で、これに対する策のようだね。
ただ、俺ならI/O層でJSON形式から変換させる。
つまりドメイン層はtoJSONを定義して、それでおしまい。それ以上の形式が欲しければI/O層で変換だ。
君のアプローチより現実的だと思うけど。
49(1): 2022/02/06(日)23:02 ID:AuLf6V7C(6/7) AAS
>>47
そりゃお前のノリでやってくれる奴はお前の畑の奴だよ。
それがJavaならそうすればいいだけ。
ただ、PODが駄目だってのはただの先入観で、
実際それでやってる奴が多くて、それでも世界が回ってるのなら、お前が勘違いしてるだけだよ。
53: 2022/02/06(日)23:46 ID:AuLf6V7C(7/7) AAS
>>50
いずれにしてもJava出身でJava流の開発をしたいのならJavaを使うべきだよ。
シェアもJSよりはあるし、実際何とかなるだろう。
外部ﾘﾝｸ:w3techs.com
> 処理効率が大事な部分でわざわざJSONを経由して効率落とすの？
開発効率を優先するって事だよ。多分Web系の連中はこっちを選択する。
（俺はWeb系ではないが）
なおJSONも効率が悪いのは無駄にダブルクオーテーションが多いくらいだから、この方式でもさほど効率は落ちないよ。
>>51
規模に対してのアプローチが根本的に違うんだよ。
Java：どんなに大規模になってもメンテ出来るようなコードを目指す。コードはひたすらメンテ。
Web系：そもそも大規模にならないように、ひたすらマイクロサービスを目指す。コードは書き捨て。
Java流のまどろっこしいコードだとサクッと変更出来ないからこうなってるのだと思うよ。
実際、Web系だとサーバー側全コードを書き直しました、とか割と聞くでしょ。Javaではあり得ないし。
だから、Web系言語で、そんなに大規模になるという事自体が間違ったアプローチなんだよ。
そういう風に言語が出来てない。toJSONという点からも分かるだろ。
俺もこのアプローチの違いに気づいた時はちょっと驚いたけど、間違いでもないよ。
これを認められないのなら、君はJavaでやるべきだよ。
あと、依存に関する考え方も違う。
Web系で危険な依存は、死んでしまう言語/フレームワーク/ライブラリに依存する事で、
具体的にはAltJSのほぼ全部(CoffeeScript等)、Vue/React以外のフレームワーク全部とかだよ。
仮にprotocol buffersを使うとして、頓死した場合、I/O部分は書き直さないといけない。
それはドメイン側のコードをいじるのと同じ手間だと思うけど。
だったら、分離した意味って無いよね。
まあいずれにしても、君はJavaを選択すべきだと思うけど。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.015s