TypeScript part4 (378ﾚｽ)
上下前次1-新
33(1): デフォルトの名無しさん [sage] 2022/02/06(日) 20:12:58.65 ID:W5e759ag(1) AAS
>>32またループしてる
そこだけバリデーションしても人間のミスはカバーしきれない
規模の小さなシステムならなんとかなるかもしれないが大きなシステムでは絶対無理
これ以上は無限ループして時間の無駄っぽいね
34: デフォルトの名無しさん [sage] 2022/02/06(日) 20:14:05.76 ID:Fo3XpFx5(11/12) AAS
>>33
そうだね。止めてもいいよ。
35(2): デフォルトの名無しさん [sage] 2022/02/06(日) 20:51:55.71 ID:AuLf6V7C(2/7) AAS
>>2828(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:34:50.15 ID:7lkHt7VO(2/9) AAS
>>25
今はなっている？ないないなってない
適当なことを言わんでくれ
JSONやXMLやバイトストリームやフォームデータのような外界の都合を吸収してシステムが扱いやすい形式に変換する(あるいはその逆の流れ)はドメイン層の仕事じゃない
それは外界とやり取りをするための専門の層の仕事だ
toJSONを呼ぶのはI/O層の仕事で、
toJSONを定義するのはドメイン層の仕事だよ。
つか、そうじゃないと無理なんだよ。
JSONでは対応出来ない型があるから、何が入っているか分からない状態ではシリアライズは出来ない。
逆に言えば何でもシリアライズ出来れば全部I/O側に任せる事は出来るのだが、
現時点で現実的にこれはバイトストリームしかないから、バイナリデータでメモリダンプ形式で良ければ出来るけど、
これはJSONともXMLとも言わないし、実際これをやってるシステムは今は無いでしょ。
36(1): デフォルトの名無しさん [sage] 2022/02/06(日) 21:05:05.78 ID:Y8lZmwFL(1) AAS
>>35
ん？別の人か？
ドメイン側が提供するのは属性の読み取りアクセスと同等の引数を受け取る完全コンストラクタオーバーロードだけ
読み取った属性を外界が要求する形式に整形、シリアライズする(あるいはその逆)のはIO層の仕事
どの外界とどんな形式でやり取りするのか？
ドメイン層はそんなことは知らないし知ってはいけない
だから外界に依存しない純粋な読み取り属性とコンストラクタでIO層と連携する
IO層はそのデータをどうすべきか全て知っている
37(3): デフォルトの名無しさん [sage] 2022/02/06(日) 21:14:45.88 ID:AuLf6V7C(3/7) AAS
>>36
まあそれでも出来るけど、それが面倒で二度手間で意味無いからみんなPODを使ってるんだと思うぞ。
FizzBuzzEnterpriseEditionとか、君は本気でやりそうだね。
外部ﾘﾝｸ:github.com
38: デフォルトの名無しさん [sage] 2022/02/06(日) 21:24:14.91 ID:Fo3XpFx5(12/12) AAS
>>37
なんだこれww
39: デフォルトの名無しさん [sage] 2022/02/06(日) 21:25:43.66 ID:7lkHt7VO(4/9) AAS
>>37
君も話がループしてるね
面倒だからPODで済ませるで通じるちっぽけな規模ならそれでいいんだよ私は一貫してそこは否定してないでしょ？
それなりに規模が大きくなった時の話をしてんの
FizzBuzzをエンタープライズの手法で作るのが馬鹿馬鹿しいのと同じように
エンタープライズのシステムをFizzBuzzを書くようなノリで作るのも馬鹿馬鹿しいってこと
40(1): デフォルトの名無しさん [sage] 2022/02/06(日) 21:33:21.13 ID:7lkHt7VO(5/9) AAS
>>35
ちなみにバイナリでシリアライズするのはprotocol buffersとか普通にあるよ
で、どんな形式で通信すんの？JSON？バイナリ？XML？CSV？
そんなのはドメイン側は知りたくない絶対に知りたくない
ドメイン側がシリアライズの責務を負ってしまったらじゃあ通信の形式が増えるたびにドメイン側を拡張するのか？
そんなのドメイン側の本質とは全く関係ない通信様式の問題なのに？
41: デフォルトの名無しさん [sage] 2022/02/06(日) 22:02:56.26 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のノリでプログラミングをしてる。
42(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:16:09.49 ID:jR6D7dXS(1/3) AAS
PODがダメなら普通にclassを使えばいいじゃない
その class に完全コントスクラタと toJSON を実装すればいい
つか贅沢言いすぎや
TSほどJSON API と神話性高く、堅く書けて、ほどよく柔軟な言語ないで
ワイはバックエンドをGoで書かされているが、言語機能の貧弱さに発狂しそうや
爆速でコンパイルできても爆裂バグだらけじゃ話にならん
43: デフォルトの名無しさん [sage] 2022/02/06(日) 22:20:03.49 ID:jR6D7dXS(2/3) AAS
>>37
ヤバスギでしょ
44(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:29:45.95 ID:7lkHt7VO(6/9) AAS
あらゆる形式に対応するためじゃない責務を明確に分けるため
仮に変更される可能性がなければ１つの関数でシステムを組むのか？そうはならんやろ
変更される予定がなくても責務は分けて作るんだよお仕事ではね
ProtobufはgRPC
バイナリで有名なのだと他にもMessage Packとか
こっちはゲームとかfluentdで有名
君はFizzBuzzのノリでエンタープライズ開発しそうだね
45(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:30:03.08 ID:Uni4uKu0(1) AAS
そのDDDの文脈でTSだとバリデーションが必要で
GoやC#だとバリデーションが必要ないケースってどんな場合のこと？
46: デフォルトの名無しさん [sage] 2022/02/06(日) 22:33:52.37 ID:jR6D7dXS(3/3) AAS
>>45
Goは完全コンストラクタを実装できない、誰でもインタスンス作り放題ヤリ放題だからバリデーションなんかいらんのや！
バリデーションなんて軟弱フニャチンオカマ野郎がへっぴり腰を振ってるようなもんだ！
ﾌｧｯｷｭｰLGBT！
47(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:50:56.58 ID:7lkHt7VO(7/9) AAS
>>42
TypeScriptでもそうすれば良いじゃんってのはその通り
別にTypeScriptがclass使えないとかそういうことを問題視してるわけじゃぜんぜんないんだ
ここで最初に戻ってよくレスを読んでみて
私が提起した問題点はこれね
「PODの濫用が標準的なコーディングスタイルとして受け入れられてる」
この問題に関しては言語自体の話題じゃないんだよ
ようするに今日やったような問答をTypeScript人材を雇うと毎回全員にやらなきゃならない可能性が高いってこと
これじゃ申し訳ないけど仕事にならないよ
なので鯖サイドではTypeScriptは残念だけど人集めの段階でNGってことになるわけ
規模でかくなるのわかってるんだから最初から鯖サイドではちゃんとレイヤ分けましょうねクラス使いましょうねSOLIDなコード書きましょうねでスッと話が通じる人が多い言語で計画立てたいわけさ
そうなると古臭いけどJavaなど無難な選択肢しかないんだよな…
48(1): デフォルトの名無しさん [sage] 2022/02/06(日) 22:57:06.33 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): デフォルトの名無しさん [sage] 2022/02/06(日) 23:02:11.49 ID:AuLf6V7C(6/7) AAS
>>47
そりゃお前のノリでやってくれる奴はお前の畑の奴だよ。
それがJavaならそうすればいいだけ。
ただ、PODが駄目だってのはただの先入観で、
実際それでやってる奴が多くて、それでも世界が回ってるのなら、お前が勘違いしてるだけだよ。
50(1): デフォルトの名無しさん [sage] 2022/02/06(日) 23:08:32.84 ID:7lkHt7VO(8/9) AAS
>>48
うん
TypeScripterとは分かり合えない人が多いだろうなとは思ってたけど君とは特に分かり合えないと思う
関数１つでシステム書く人を理解するのは私には不可能だ
365をリテラルで書かないのはDDDとかそれ以前の問題だと思うよ
君の書いたコードって四年に一回ぐらいバグ出してない？大丈夫？
処理効率が大事な部分でわざわざJSONを経由して効率落とすの？
ライブラリ開発者が必死になって直列化コストを削減してくれたのを嘲笑うかのような所業
やっぱり理解できないや
51(1): デフォルトの名無しさん [sage] 2022/02/06(日) 23:09:14.59 ID:7lkHt7VO(9/9) AAS
>>49
それで回る規模の世界はそりゃ回るだろうね
これも何度も言ってるよね
52: デフォルトの名無しさん [sage] 2022/02/06(日) 23:34:35.72 ID:EROXxvgE(1) AAS
なら、その規模を確認してからでよかったんじゃね？
53: デフォルトの名無しさん [sage] 2022/02/06(日) 23:46:30.23 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を選択すべきだと思うけど。
54: デフォルトの名無しさん [sage] 2022/02/07(月) 03:29:33.54 ID:yhez4jOW(1/12) AAS
あと、パフォーマンスレンジの選択も間違ってる。
スクリプト言語は、チャッチャと書いてチャッチャと動かす為の言語であって、
ゴリゴリ一生懸命コードを書いて、パフォーマンスやメンテナンス性を得るための言語ではない。
つまり、今回で言うと、
TS/JSはJSONで全く問題無い場合に使う言語であって、
JSONではパフォーマンスに問題があると分かっているのなら、GoかRustを使うべき。
勿論Javaでもいいが、RustならJavaより速い。
だからこそ逆に、手抜きして何が悪い！ってことになる。
要求仕様が「オブジェクトを復旧できること」なら、
一番簡単なのはJSONで、これを使う人が多いのは当然だ。
一々自前でコードを書きたくなければPODになる。これがいいかどうかはさておき。
(ただまあ俺も、Web系の連中はJavaのstaticおじさんを馬鹿にする割には
書いてるコードがstaticおじさんと同じなのはどうなのよ、とは思ったが)
ちなみに主張されてるようなケースでJavaならイテレータでも渡してI/O側でシリアライズするのか？
単純なイテレータだと階層があったら厳しいから、階層も跨いでいけるイテレータを渡す事になりそうだが、
それでもデータの中身が何か知ってないとシリアライズは厳しくて、
現実的に完全に分離するのは無理だと思うが。
なおメンテナンス性についてはTS/JSは以外に高い。
こういう構造にしたい、というのはあっけないほど簡単に記述出来るから、分離だけは簡単だ。
(ただ、その分離の意味があるのか？が俺には疑問なのだが)
55(1): デフォルトの名無しさん [sage] 2022/02/07(月) 03:30:51.04 ID:yhez4jOW(2/12) AAS
それから、規模については他の人も指摘してるけど、一体何万行のTSを書く気だ？
やれば分かるが、鯖なんて結局DBから読んで加工して吐くだけだから、
APIだけ(HTML生成無し)なら3,000行も書けばいっぱしのサービスは出来てしまう。
あっけないほど簡単にね。スクリプト言語だから記述レベルが元々高いってのもあるけど。
(HTML部分はどこまで凝るかだけど、コード自体は独立してるから分量が多くなっても何ら問題ないはず)
Javaから見ればWeb系は多分1/10位で開発してる。
Redditで6人(言語不明)、diggも6人(Go)、discordが35人(Rust)とかだったと思ったよ。
そもそもそんな「大規模開発」になってない。
この辺を知って、俺は「あれ？これはJavaのアプローチの方が間違ってたんじゃね？」と思いだしたんだよ。
OOP：どんなに大規模なコードでも取り扱ってみせる！
スクリプト言語：そもそも複雑にならない範囲に留めろ
Javaから見ればWeb系は馬鹿ばっかなのも事実だろうけど、JavaはJavaで馬鹿な事をやってる。
だから特等席を与えられていたのにJSに駆逐された。(クライアントサイドでは)
それって鉛筆でよくね？ってのを考えた方がいいと思うぜ。
56: デフォルトの名無しさん [sage] 2022/02/07(月) 06:51:13.72 ID:b69Z+ASC(1) AAS
TSの知識が無くTSの開発者文化に馴染めず、理解してない言葉を並べ、決して間違いを認めず、自分のやり方に固執し、目の前にある概念を理解しようともしない。
う〜んこのおっさん。
57(1): デフォルトの名無しさん [sage] 2022/02/07(月) 10:07:24.70 ID:WuDoUI67(1) AAS
>>55
ううむ…せめてレス読んで理解した上で応答してほしいんだが…
小さなシステムでやり方にこだわる必要はないってのは深夜3時までかけて書いた情熱的な作文でいちいち主張しなくても私も最初から認めてることでしょ？
昨日議論したのはそういう手法が通じない規模のシステムの話ね(何度もそう書いてるはずだが)
大きいシステムではうまくいかないよという話をしてるのに
その応答が小さなシステムならうまくいくから問題ないでは話が噛み合うわけがないよね
上下前次1-新書関写板覧索設栞歴
あと 321 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s