DDD、CQRS、ES-それだけの価値がありますか、それとも単なる時間の無駄ですか？
私は現在のプロジェクトでakkaの助けを借りて、DDD、CQRS（サガ、ファイアアンドフォーゲットプリンシパルなど）、ESを適用しようとしています。実際のプロジェクトではこれまでに一度も行ったことがない（ほんの少しだけ演奏しただけ）、理論的には素晴らしいと思います。
しかし、それは時々私を苛立たせます、時々それは単なる流行語だと思います。
実際のプロジェクトでこれらのテクニックの経験はありますか？もしそうなら、それは価値があるのですか、それともシステムを複雑にするだけですか？
まあ、それらは3つの別個のものであり、彼らは単なる流行語ではなく本物です。だが....
ドメイン駆動設計。これは、少なくとも「ライト」な方法で、今では一般的に静かに使用されているのを見てきました。システムを定義してコンポーネントに分解することは役立つと思います。
コマンドクエリの分離。読み取り専用dbと書き込みdbが必要な場合もあります。コマンドオブジェクトなどを使用してパターンを普遍的に適用しても、私がそれを試みたのを見たところで成果が得られないようです。
イベントソーシング。これがシステムの一部に適用されるのを見てきましたが、イベントの監査証跡よりもはるかに多くの利点を提供するものとして私を襲ったことはありません。それは中程度の複雑さを追加し、いくつかの重要なエラー条件、衝突するイベントなどについて考えることを強いるので、それに大きな副作用があります。
これらのことについてはいつものように、それらが何を意味するかについての複数のビューと、各ビューを実装する複数の方法があります。
単一の実装が人気になり、時間の経過とともにスラッシュされる場合、成熟していると言えます。
これが発生すると、選択した実装を誤って適用したり誤解したりする可能性は非常に高くなります。つまり、人々はややハックな解決策になってしまう可能性があります。
新規のパターンを理解してテストするために余分な時間をかけ、アプリのコアで未熟な技術を使用しないようにする必要があります。
ソフトウェアエンジニアリングで最も重要な原則は K.I.S.S および Y.A.G.N.I の場合があります。
すべてソフトウェアエンジニアリングの原則、ガイドライン、方法論は、単に提案であり、ルートを誘導するために存在します。頭に浮かんだ最初の考えに基づいて解決策を打ち出しただけでは、他の方法で作成した解決策よりも優れた解決策になる可能性があります。
DDD、CQRS、ESなどは、理由のために人気があります-他の誰かがJust Do Itの「ナイキ」アプローチを試みたため、コードベースが Big Ball of MudTechnical Debt の膨大なバックカタログを使用して、彼らが設計またはプロセスで犯した間違いを特定し、他の人が同じ運命を回避できるようにアドバイスをまとめました（そして/またはそれらがすでに深すぎる場合にその穴から自分自身を掘る方法）。
DDD、CQRS、ES、et-alは流行語ではありませんが（実際の開発者は肯定的な結果を持つ実際のプロジェクトに適用します）、 Silver Bullets でもありません。方法論、ガイドライン、または原則の利点を理解することは、それを実践する方法だけでなく、いつそれに従うべきか、そしてそれから利益を得られない場合も理解することです。一部の問題は特に特定の手法に適していますが、他の問題には別のアプローチが必要です
質問へのコンクリート回答を提供するには「彼らはそれだけの価値がありますか？」（私が解釈すると "今すぐ使用する必要がありますか？"）は、作業している特定のプロジェクトを詳しく調べ、必要な機能のタイプに基づいて、そのプロジェクトの判断を下すことになります。提供する（現在または将来）、推定時間、複雑さ、予算、期限など.
DDD/CQRS/ESの一般的な「コスト」は、元の設計の反復と、機能していないビットの破棄またはリファクタリングに費やす時間が長くなります。これらのアプローチに従っても、最初の実装には多くの側面が含まれることは間違いありません。 'Nike'/Just-do-itソリューション。主な違いは、プロトタイプまたは初期ソリューションをまとめた後の進捗状況です。
開発者としては、DDDとCQRSを適用する方法、およびプロジェクトに適切な方法で取り組んでいるかどうかを認識する方法についての理解を深めることがより重要です。飛躍するための方法は、怒りの中でそれらを使用することです（つまり、実際のプロジェクトに適用して、快適になるまでデザインを反復することです）。
プロセスがイライラして失敗に終わったとしても、新しいことに挑戦するのに費やされる時間はめったにありません（失敗から多くを学ぶと言う人もいます）。さまざまな問題に取り組むためのさまざまな方法を学ぶために、粘り強く自分の時間を費やすことは絶対に価値があります。フラストレーションはこのプロセスの通常の部分です。それはあなたがまだ理解していないことがあるという兆候ですが、それはそれらが理解する価値がないということではありません。現在のプロジェクトで、または現在の雇用主と実際にその知識を実践していなくても、より多くの知識と理解を得ると、「より良い」開発者になる可能性があります。
それをしないでください...それは欠陥のある設計方針です。グレッグヤングでさえ、その使用に疑問を投げかけていますが、システムの混乱と混乱を広げる彼の会議を売り込んでいます。監査が必要になる特定の使用例がありますが、単純なコマンドパターンで十分です。多くのシステム設計者は、主に仲間に自慢するために、次の大きなことにメンタリティを与えていると思います。または、履歴書に追加します。最も重要なことは、製品と会社とともに成長する、信頼性が高く、保守が容易で理解しやすいシステムを構築することです。
マイクロソフト、グーグル、フェイスブック、ツイッター、主要金融機関-これらすべてのトレンディで派手なばかげたアイデアに頼る必要がなかったすべての10億ドル規模の企業。したがって、それを正気に保ち、システムを設計するときに常識を使用してください。夢中にならないで。