プログラマの雑談部屋 ★274
■ このスレッドは過去ログ倉庫に格納されています
>>779
dtoがオブジェクトなことから説明が必要な感じ? >>782
お前はまず入門しろ
言ってることが素人以前だ >>775
列挙するだけなら3つのテーブルJOINして検索するSQLを発行するリポジトリクラス1つで済むけどな >>779
アクションはUIからデータを取り出して最小限の入力チェックを行い、サービスを呼び出し、サービスの戻り値をUIに書き戻すだけ、だって教わらないのかね?世の中の平均的プログラマってさ >>784
構造体はオブジェクトの実装でしかないぞ プログラミング言語なんて1,2つでよくて契約とるところから一人でできることのが大事 >>781
dddじゃなくてトランザクションスクリプトあるいは貧血ドメインモデルやでって言いたかった
トランザクションスクリプトもoopだろって言われればまあそう ファンクションキー毎に200行くらいあって
内容がほとんど同じで、キーによって微妙に違う所がある
そんなコピペ方式の実装を見たことがある 何万件ものデータ扱うならDBとか意味あるけど
たかだかすうひゃ >>758
一度も仕事したことない奴の感想文すぎて草
ビジネスロジックが抜け落ちてる >>787
そりゃ世間はコントローラアクションからドメインクラスを呼び出すのが作法になってるからだが、はっきり言ってトランザクションスクリプトしてるとボイラーテンプレートだしな。
まあ実際にはサービスクラスpublicメソッド呼び出しにaopしてるからコントローラはその呼び出しになってるけど >>793
「少なくとも」という日本語から説明が必要な感じ? >>783
俺のはDDDに忠実な、スタンダードな設計
DDDをよく理解せずに、リポジトリとかサービスって、言っとけばいいんだろ?
みたいな、浅い理解の仕方だと、仕様とか、ポリシーといった概念が抜け落ちて、しまうんだ
すると、リポジトリにやたら複雑な検索を実行するメソッドとか、同じ条件判定が、あちこちにコピーされる、といった、なんとも残念な、エセDDDになってしまう ユーザクラスを生成してポイントと
履歴をテーブルから取得でええんじゃね?
よくあるパターンだとserviceで判定してactionにSMS通知フラグを
返しやるみたいな >>796
さすがに条件の一つ一つをオブジェクトにするのはアホだわって話が通じないところを見ると真正だな? >>796
正直うちは基幹システムメインだから仕様変更多くなくてdddにする意義が見いだせなくてなー... >>796
SQLである程度絞らないとメモリに大量に読み込んでロジックで抽出する富豪的な書き方になるだろ
まぁ今はそれでも許される時代になったのか >>786
ううむ、バッドプラクティス
そのまま進むと、リポジトリの責務が際限なく膨らみ、様々なビジネスロジックの置き場と化す
悪いことはいわん、お若いの
リポジトリはシンプルに保つのじゃ
なお、CQRSで割り切って、短いキャンペーンの間なら、表示までは、テキトーなSQLでええやろ、ならおk
ずっと残すものは、綺麗に作れ。これ大事 >>798
一回のキャンペーンの条件に過ぎないものを全部オブジェクトとしてハードコーディングするのはさすがにアホだよね >>798
彼が言いたいのは仕様をDRYしろって大原則が抜け落ちるとdddのメリットの9割が消えるってのが主張したいことだろ
結果的に条件が横断的な仕様なら個別に別れてなきゃいかん >>804
60歳をハードコーディングすることのどこがDRYだw マイクロサービスはそうするよ
という肯定意見がないのでこのスレはその程度なのだろう 何万件ものデータ扱うならDBとか意味あるけど
たかだか数百件扱うのに導入する意味が分からないよ >>798
一つ一つとか関係ない
それが業務で定義されてるのなら、どんなに小さくても、作るのだ
システムは、気持ち、で開発するのではない
業務、ドメインを再現するのじゃ
それがDDDなのじゃよ 条件をオブジェクトにするやつって複数のキャンペーンにどう対応するんだろう
全部クラス化するのか? >>808
とりあえず入門しろ
お前の想像とは全然違うものだから >>810
要件定義からの仕様書からの詳細設計書だが? >>799
変更が多い時に最も大切なことはテストだろう
テストしやすいようにDDDしよう >>809
クラス化しても、後でそれでカバーできない条件ってのが絶対出てくるから、クラスの書き直し、それに依存してるコードの修正、そしてテストも失敗するから、大量のテストの修正ってパターンだな DBにする理由は永続化でデータ件数とかより
こっちかなと
テキストとかCSVで保存すると排他制御とか
行単位では出来ないし、何がどれやら作った人にしか解らなくなる 検索条件の一つ一つをクラス化しなきゃいけないと思ってるやつは電卓を作るときはボタンの一つ一つを全部クラス化しなきゃいけないとか思ってそうだな
Value Objectを知らんのだな >>814
そろそろ自分でもイタいこと言ってることに気づかないか? まあ、皆自分の経験で仕事の規模も類推してしまいがちで
そのため過度に大げさになったり、小さくまとまり過ぎる事もあるだろう >>815
それ、DBでも同じじゃね?
で、ドキュメント化されてれば良くね? 結局、SQLで書きにくい条件は、一旦メモリに読み込んでコードでゴリゴリフィルターかけて抽出するって感じ?
で、ゴリゴリフィルター部分をオレオレクラスで華麗に設計すればいいのか 10kmラン54m44s
用もないのに有明まで走ってきた >>820
速度と転送量に問題が出ない程度に絞って読み込んじゃってるかな?
でも対象が絞れないほどデカイときは注意 >>801
もしかして、仕様クラスを理解してない
エンティティが満たすべき、条件を抽象化するためのクラスだよ
だから仕様っていうの
リポジトリは、渡された仕様を満たすエンティティを、検索するだけ、だから業務の事を知らなくていいので、スッキリ
仕様を満たす、エンティティだけが、メモリに読み込まれるので、メモリ効率も抜群 利用促進の案内クラスを作っておいて
条件や内容は可変にしておけば、後々楽だろう >>819
うーん
作った人にしか解らないってトコ?
テキストは行にコメント付けられない
( ー`дー´)キリッ 前向きに明るくポジティブに
みたいな愚痴も言えない空気押し付けられるのどう思う? >>805
この場合は、キャンペーン対象の条件を仕様として定義する、のだから60がハードコードされていても、おk SQLでも普通は一気にメモリに読み込むんじゃなくて、1件ずつ読みながら処理だからそれがネックになる事はないわな
SQL自体にしてもSQLビルダーで複雑な条件を動的に生成出来るし 年齢指定なんかは、運用時に自由にできたほうが便利だと思いますが
いかがですか SQLはまとめてデータ取れてる気がすんだけど
それって実際は1件ずつFetchした結果を見てるから
そう感じるってだけなんかな? >>809
キャンペーンごとに作る
var spec1 = new キャンペーンX対象者仕様();
var spec2 = new キャンペーンY対象者仕様();
var spec3 = new キャンペーンZ対象者仕様();
users.find(spec1);
users.find(spec2);
users.find(spec3);
繰り返しキャンペーンで、毎回微妙に変えたいならパラメータ化してもいい
var spec4 = new 定期キャンペーンW対象者仕様(age: 60, addressNearBy: "◯×");
users.find(spec4);
エレガント、、、
実にエェエエエエエレガントッ! >>811
ぶっちゃけ入門が元々のdddかって言われるとかなり首を傾げたくはなるんだどね
まあ、現実解としてはこうなるよなって実装になっててより実務的なんだけど 性別の指定がありませんが、これは担当者様の見落としですか? なんというか、世間的にもdddしなくてもvoガッツリ育てりゃどうでも良くねってなってきてるフシあって、少なくとも2000年代に主張されてたdddとは違うプラクティスになってるよな >>830
それは書き方次第
一気にも取れるし、カーソルで一件ずつも処理できる
C#だと、Listに読み込むか、IQueryableで遅延評価するみたいな感じか
レコードを全部オブジェクトに変換してから抽出しようとするとメモリ使う >>829
時と場合
仕様クラスのコンストラクタで、可変にしつつ、デフォルト60とかでもいい
大事なのは、そのキャンペーンを、何度やるか
2回目が決まった時に、可変にしたって、いい
でも、一回しかやらない場合でも、業務を明確化するために、クラスにする
それは、条件がどんなに小さくても、だ >>752 みたいなお題だと、
検索による一覧画面は実装済みで
それを眺めてる内に「ボタンで案内を送れたら便利かも」
って思いつくような経緯もありそうですね >>830
内部的には全て1件ずつループしてる
使う側が全部リストに入れてから使うか、逐次処理するか選ぶ >>830
IQueryable じやなくて、IEnumerable だった ポイントテーブルが処理のトリガーなのか
ユーザークラス生成の前にポイントの読み込みが先ですわね
こりゃお恥ずかしい ガハハハ 古えの90年代に存在したADOのRecordSetは破棄するまでDBに繋がったまま一行ずつフェッチする例だった気がする
メモリが少ないしそうなるよなって思うやつ >>836
というか、使う側のメンタリティが、変わった、のだろう
完全性だのなんだのと、とにかく、データが厳密であることを、求められた、昔は
大衆が、稀にしか起きないデータ誤りなら、運用でカヴァーした方が、安い、実行速度が速い、と気付いた 検索結果オブジェクトと
案内の内容オブジェクトを
いい感じで連携させればいい お前らが華麗に設計して作ったクラスも、チームの他のメンバーからは誰にも気づかれず二度と再利用される事はないのであった… >>847
まあ、悲しいけど、悲しいけど、これが現実よな 再利用なんて実感として1割以下なんだけど世の中はそこそこ再利用されているものなのか? Javaとデザインパターンかなり覚えたけど
結局、設計する事はなくソース解析の時にしか約に立たなかったわ
だから土方は土方のままなんだわ
Javaは大規模システムに向いているから商流によって作業が違うので
規模の大きな会社に居ないとド底辺作業員になるというロジックが成り立つ
のでJavaを捨ててpythonReactマンになりますた 汎用的なクラスってのはいろんなパターンを想定して無駄に複雑だったりするからな
まずそれを理解するコストが面倒くせ!ってなるんよ 今日はいい議論ができた
5chもたまには有意義なのだな >>850
そりゃデザインパターンの大半はフレームワークを作る側か、シミュレーション分野などでしか使わんからな
普通の業務システムではフレームワークの選定とオレオレフレームワークに調整する作業者でないと、かっちりハマる機会はあまり無い >>853
キャンペーンのたびにコードをデプロイし直すなんて仕様が許されるわけないだろ 休日だからS級からZ級まで色んなプログラマが来てる
いや、S級は来ねえかw >>856
そうっすよね
個人的には業務をシステムに落とし込む段階で
オブジェクト指向とかデザインパターンって約に立つと
思ってたといか想像してたけど
そういう機会はないまま俺のJava道は終わりを告げたのだった >>857
いや許されるだろう
今はddとやかく言うよりdevops進めて週一リリースをできるようにする時代だ Javaは勉強するものであって実務で使う物ではない
例外で金融だけはJavaがベストだけど >>857
緊急に決まったキャンペーンでいちいち呼び出されて設計実装テストアップロード更新とかやってらんないよな
キャンペーンテーブルを作ってそこにクライアントがデータを打ち込めるUIを作るに決まってる コーディングするこっち側が
可変部の見当付けておいて、
なんなら半自動でソース生成すればいい >>857
許される
つか、今どきは、みんな、コードマージして、自動でポン、だろ
承認ボタンを間に挟むかど、うかは、組織ポリシーだが >>861
週一リリースできるとこなんて限られてるぞ無職 年齢性別条件のキャンペーンなんて普通は一度きりではないから、DBにキャンペーン条件テーブル作ってJOINで取ってくるよね 普通じゃない奴が普通じゃない奴に発注した仕事を
まともなプログラマがこなす場合も、無くは無い お前の作ったブランチにdevelopをマージすんだよってんのに
developにマージすんだよなぁ あのオッサン 結局今日の成果は、検索条件クラスとやらが一個作られただけか
これもオブジェクト指向なのか? >>867
うちの別チームはやってるぞ
つかバグ対応の緊急リリースなら3日以内にリリースとか普通にやるだろ うちは週3でdeployしてるけどweb屋だからか? >>864
これは、いい指摘だ
キャンペーン対象者の仕様クラスを作って、キャンペーン対象を抽象化すると、それをシリアライズして、データとして管理可能に、なる
キャンペーン一覧View
キャンペーンON/OFF機能
キャンペーンパラメータ変更機能
などといった、ビジネスサイドが、欲しがる機能が、容易に、手に入るのだ BtoCにいきたかったがそれもかなわない
なにもかなわない 通知ボタンは明日までになんとか実装しますんで
もうちょっと待っててください ■ このスレッドは過去ログ倉庫に格納されています