DDDわかるプログラマー来て

>>28
自動テストで使うActionsの料金、目玉が飛び出るんだよね

>>33
通知をDBとジョブでやってたのを別サービスに飛ばして処理するように変えた時
そもそもリポジトリという概念がないのでそうなった

>>17
こういうのって何回かやってみても失敗するもんなの？

>>37
並列処理するとDBのバッティングが起こるというのがあまりわかってない
たとえばテストケースを7分割して別のデータベースで実行すれば単純にテスト時間が1/7になるという話ではないのか
トランザクションはテストケースごとに行っているはず

並列処理のためにトランザクションでガードしてるっていうのは、
つまり、あるインスタンスでのテストが終わるのを、別のインスタンスのテストが待っていて、そのテストが終わるのを他のテストも待っているみたいな依存関係が発生しているってこと？
それだと重いんじゃないか。並列できてないような気がするが…

正規化しすぎが問題なら、必要なデータはほとんど同じだと思う
それなら共通基盤となるコンテキストを用意しておいて、
各テストではこのコンテキストで用意したレコードをカスタマイズしてテストするみたいにするとだいぶ時間短縮できそうではある
テスト終了後にそのカスタマイズ情報は破棄する感じ
こうするとテストケースを書くときも行数が減り見通しがいいはず
（問題はみんながみんな多種多様な準備をしているからぐちゃあっとなっているところかも。もしそうならメンバーはテスト書くとき苦悶の表情をしていそう）

昔亀有の一帯にDDD殺しますって落書きあったのわかるやついる？

並列テストにおいて割とメジャーな手法だと思ってたんだけど違うのか

>>45
インスタンス毎にコンテナでDB建てて、それに接続
アプリケーションレベルでの並列処理ではさっき言ったトランザクションでの分離で5並列にして動かしてる
現状上手く動いてるから並列処理に関しては課題に感じてない。

MQってなんだ？Message Queue？
あんまりストレージ/レポジトリとしてMQを使う印象がない
何かを非同期実行してデータベースに保存するために使う感じなのか（保存 / 遅延保存みたいな）
責務的にはアクションとかサービスみたいな印象だ
もしレポジトリとしてMQを使うのならば、クラスごと分けるのが正道な気がするな
（じゃないと保存のためのフォーマットが依存し合う）

俺の場合使用側で分岐ロジックを書く
一方で使用側にそういうロジックが大量発生する場合はなんかおかしい気がする
（そもそもサービスが違う/やりたいことが違うというか）

>>22
俺はそれはテストが重いことの原因がDBアクセスが遅いというのが真の原因なのか疑問に思う
それの根本はORMの使用によってN+1問題が発生していたり、テストの前準備のために非常に多くのデータを読み込んでいることによる気がする

たとえば1つの単体テストを実行するごとに大量にデータアクセスが発生すればそれはめちゃくちゃ重い
モック化することによって解決する問題かは疑問が残る。それにDB特有で発生する問題も検知しにくそう

テストを並列化するとか、非常に重いテスト部分を解消するとか、全体にわたってslowになっているクエリを高速化するとかに課題がありそう
しらんけど

>>25
ちゃんとテスト毎にトランザクション張って他のテストに影響が出ないようDBをセットしつつ1インスタンス7並列でそれを複数のインスタンスで分割して動かしてる
それでもテストが追加される度にどんどん遅くなってく

正直DBアクセスを伴うテストはシナリオテストだけで良くて、ビジネスロジックのエッジケースは単体テストでカバーしてあげたい

抽象化された設計のメリットって外側の交換可能性なんだけど
実際やってて思うのは
プロジェクト内でDBが変わることなんてないんだよな
リポジトリとか抽象化したって結局
本で書かれてるような「DBをファイルにすることすらできる」とか現実には起きない

>>8
ちげーよ！

オススメはAAAだよ！

>>28
あとORMでDBへの接続が失敗したりエッジケースでシンタックスエラーはいた場合のテストケースってどうやって書いてる？
モックできないとその先の処理をテストできないんだよね

遊戯王のカードの次に流行らせようとして失敗したヤツか
ダンジョンダイスドラゴンズだったっけ？

>>21
Arrange Act Assertか
なんかうちではGWTつかってる

デデデ大王じゃない😡

デデデ大王じゃない😡

俺が並列テストするときは同じDBにはしないかも
200分割するなら200個データベースを作る感じ
同じDBなら200分割しても10分割してもトランザクション待ちが多くなって効果が見込めないような気がする

これかな
https://irof.hateblo.jp/entry/2021/09/21/101205

マイクロサービスで適切にサービス分割するような場合は確実にやったほうが良さそうだけど、そもそもマイクロサービスがちゃんと必要になるレベルの規模の開発じゃない場合はいらなくない？

イベントどんぶり

>>29
テストケースごとにトランザクション張るのは遅いのとは関係ないと思う
1個あたり100msで終わるなら1000ケースあっても100秒で終わる計算

俺が見てきた案件ではテストケース用意のために不要なデータまでぞろぞろ大量に作りまわる処理が多くて
そこで異様に重くなっているのが多い印象
つまり各処理が重いというよりかは準備段階で重い（INSERTやCREATEやUPDATEが大量に走ってる？）

ビジネスロジックはDBアクセスを伴う必要はないというのはそうだと思う
ただ、既存のテストが重いのは↑によるもののように見える。しらんけど

>>5もそうだが、人によってDDDとはなんぞというところから話が違う
異なる母体から集まってきたエンジニア同士なのだから使用語彙が大幅に違って当然
まずそこの部分の一致から始めて、「これって何よ」「これはこれだよ」という認識の突き合わせから必要だよね？ということをずっと言っている印象

基本的にはEric Evansが考えるDDDが聖典だから、それがどれだけ自分たちの持つプロダクトに活用できるかを知るのが重要かと思う
システムアーキテクトは、DDDを学習してそれをカスタマイズしてプロダクトづくりに応用することが使命だと思う（これは完全に俺の意見）

DDD知識を保有するメンバーが多数派ならその部分の会話についてハイコンテクストで済ませることができるからそれは有用
まあこれはコモディティ/民主化された知識あるあるだから、別にDDDに限った話ではないけど

>>10
やっぱそうよな
サービスの規模的に絶対導入すべきでない場合に導入すると終わるよな

チームメンバーが理解しないまま導入してもただただ複雑性だけが残るような気が知る

DDDやクリーンアーキテクチャや果てはGoF等々もかもしれないけど
開発を円滑に進めるための前提知識ってだけで導入するとか言う仰々しい物ではないと思ってる
ボブおじさんも似たような事書いてた気がすんな

オナニーと営業だろ
客向けに最新の技術でコーディングなんてあほらしいこと言ったりさ

>>18
マジでこれね
「取り外しできるよ！」という部分がメリットに感じない
ほとんど多くのプロジェクトでは取り外しすることはないと思う。特にDBや選択したフレームワークなど
ただし十分規模が大きいときは別かも
どこを拡張するかどこは拡張すべきでないかの判断は主観とか経験とかによりそう

>>19
導入すべきでないとはいわないけど、自分が伝道者となって長期的に見ていく気がないなら単なるオナニーになるかも
DDDに限らないけど

打倒カービィ

〇〇を導入とか仰々しく言うやつは大体アジャイルやOOPで失敗した奴らと同じ匂いするわ

>>36
なんか見当違いなこと言ってたわ
DDDにするならmqはリポジトリには置かんよな