DDD、CQRS、イベントソーシングをどのように試したか、どのような結論を出したか

約3年前から、 Spec By Example 、 Domain Driven Design、CQRSの原則を仕事に使用しています。 この間、.NETプラットフォームでのこれらのプラクティスの実践的な応用で経験が積まれました。 この記事では、開発でこれらのアプローチを使用したいチームに役立つかもしれない経験と結論を共有したいと思います。

DDD 結論

1. とても高い
2. 確立されたビジネスプロセスでうまく機能する
3. 必要なことを行う唯一の方法である場合もあります。
4. スケーリングが不十分
5. 負荷の高いアプリケーションに実装するのが難しい
6. スタートアップでうまく動作しない
7. レポートには適していません
8. ORMに特別な注意が必要
9. エンティティは誰もが独自の方法で理解するため、回避するのが最善です。
10. LINQでは、仕様の標準実装は「機能しません」

とても高い

私がトピックについて議論したDDDを使用するすべての開発マネージャーは、主にEvansの書籍「DDDの原則に違反せずにFooBarを作成するにはどうすればよいですか？」



グレッグヤングによると、GoogleのCQRSグループで最もよくある質問は次のとおりです。 RAMで集計のすべてのルートを取得すると、すべてが遅くなり始めます。 どうすればいいですか？」 この質問には明らかな答えがあります。「SQLクエリを記述する必要があります。」 ただし、手動のSQLクエリを記述することは明らかにDDDルールに反します。



エヴァンス自身はヤングと同意し、本は別の順序で書かれるべきであると述べた。 重要な概念は、 EntityとValueObjectではなく、 Bounded ContextとUbiquitous Language です 。



レポートにはドメインモデルは必要ありません。 レポートは単なるデータテーブルです。 データドリブンは、ドメインドリブンよりもレポートに適しています。 一見すると、この時点で、DDDが悪いと言う必要があります。 しかし、これはそうではありません。 DDDを使用してレポートを作成するだけでは、真の境界コンテキストではありません。

制限されたコンテキスト

1. 英語のファウラー
2. 私の資料はロシア語です

DDDの最も重要な論文は、アプリケーション全体に対して1つの大きなドメインモデルを開発しようとしないことです。 これは複雑すぎて、誰も必要としません。 企業管理のレベルで、すべての部門が同じ用語を使用し、すべてのビジネスプロセスを同じように理解することが決定された場合にのみ、アプリケーション全体に対して1つのドメインモデルを作成できます。

誰もが独自の方法で理解するエンティティ

用語をチームメンバー全員と合意することは非常に難しいことを確認しました。 Entityという用語は障害になりました。IEntity<TKey>インターフェイスを使用しようとしましたが、IdがValueObjectsを使用してコマンドを送信できることにすぐに気付きました。 そのようなオブジェクトにIEntity <TKey>を使用すると混乱するため、 IHasIdを優先してIEntityを放棄しました。

DDDではORMに特別な注意が必要です

スタックオーバーフローでのDDDのNHacknate対Entity Frameworkについては、かなりの数の議論があります。 NHibernateの方が一般的に優れていますが、まだ多くの問題があります。 ORMを使用する場合の標準的なアプローチは、パラメーターなしのコンストラクターを使用し、プロパティセッターを介して値を設定することです。 これはカプセル化の中断です。 コレクションとLazy Loadには特定の問題があります。 さらに、チームは、「ドメイン」が終了し、「インフラストラクチャ」が開始する場所と、永続性無視を提供する方法を決定する必要があります。

LINQでは、仕様の標準実装は「機能しません」

EvansはJavaの世界の男です。 さらに、本はずっと前に書かれました。

public abstract class Specification<T> { public abstract bool IsSatisfiedBy(T entity) };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このインターフェイスを使用すると、メモリ内のコレクションを操作できますが、SQLクエリの構築にはまったく適していません。 最新のC＃では、 このオプションの方が適しています。

 public abstract class Specification<T> { public bool IsSatisfiedBy(T item) { return SatisfyingElementsFrom(new[] { item }.AsQueryable()).Any(); } public abstract IQueryable<T> SatisfyingElementsFrom(IQueryable<T> candidates); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

応用分野

ドメインモデリングは簡単な作業ではありません。 DDDでは、いくつかの分析タスクを開発者に委任します。 これは、エラーのコストが高い場合に正当化されます。 コードがどれだけ速く書かれていても、システムが正しく動作せず、お金を失ったとしても、システムがどれだけ速く動作するかは関係ありません。 実際、逆のことが言えます。HFT用のソフトウェアを開発していて、その動作方法を完全に理解していない場合は、ソフトウェアの速度が低下するか、まったく動作しないことが望ましいです。 だから、少なくともあなたは超高速でお金を失うことはありませんが、正しい取引ではありません:)



持続不可能なビジネス（特にスタートアップ）では、多くの場合、対象モデルの理解がありません。 すべてが毎日変わります。 これらの条件では、ビジネスプロセスの参加者に単一の用語を使用するように要求することは無意味です。

Cqrs

結論は明らかです。DDDは「銀の弾丸」ではなく、残念です:)ただし、特定のバウンドコンテキストでのDDDの「ターゲットアプリケーション」により、大きな利益を得ることができます。



1980年、バートランドマイヤーは非常に単純な用語CQSを策定しました。 2000年代初頭、グレッグヤングはこの概念を拡大し、普及させました。 そのため、CQRSが登場しました...そして、CQRSは繰り返し誤解されたという意味で、DDDの運命をほぼ繰り返しました。



インターネットにはCQRSの資料がたくさんあるという事実にもかかわらず、誰もがさまざまな方法で「準備」しています。 多くのチームは、CQRSの原則を使用していますが、CQRSとは呼びません。 システムにはCommandおよびQueryの抽象化がない場合があります。 IOperationまたはFunc <T1、T2>およびAction <T>に置き換えることもできます。



これには簡単な説明があります。 最初のCQRSの結果は、次の画像のようなものを生成します。







Dino Esposito はこの実装をDELUXEと呼びます 。 ここでのポイントは、CQRSが主にイベントソーシングのコンテキストでグレッグヤングに関心を持っていることです。 実際、イベントソーシングではCQRSを使用する必要がありますが、その逆は必要ありません。







したがって、CQRSを使用すると、アプリケーションスタックを読み取りと書き込みに分割し、読み取りスタックのドメインモデルを使用しないことで、ブレーキレポートの問題を解決できます。 読み取りスタックは 、異なるデータベースおよび/または他のより最適なデータアクセスAPIを使用する場合があります。



アプリケーションをコマンド、ハンドラー、およびリクエストに分割することには、予測可能性の向上という別の利点があります。 DDDの場合、特定のビジネスロジックを探す場所を知るには、サブジェクト領域を理解する必要があります。 CQRSの場合、プログラマーはコマンドハンドラーで書き込みが行われることを常に認識しており、クエリはデータへのアクセスに使用されます。 さらに、一見したところ明らかでない利点がいくつかあります。 以下で検討します。

CQRSの主要な調査結果

1. イベントソーシングにはCQRSが必要ですが、その逆は不要です
2. 安い
3. どこにでもフィット
4. スケーラブル
5. 2つのデータストアは必要ありません。 これは可能な実装の1つであり、必須ではありません
6. コマンドハンドラは値を返すことができます。 同意しない場合は、 グレッグヤングとディノエスポジトと議論してください。
7. ハンドラーが値を返した場合、スケールは悪化しますが、非同期/待機がありますが、それらがどのように機能するかを理解する必要があります

CQRSのメインインターフェイスは次のようになります 。

  [PublicAPI] public interface IQuery<out TOutput> { TOutput Ask(); } [PublicAPI] public interface IQuery<in TSpecification, out TOutput> { TOutput Ask([NotNull] TSpecification spec); } [PublicAPI] public interface IAsyncQuery<TOutput> : IQuery<Task<TOutput>> { } [PublicAPI] public interface IAsyncQuery<in TSpecification, TOutput> : IQuery<TSpecification, Task<TOutput>> { } [PublicAPI] public interface ICommandHandler<in TInput> { void Handle(TInput input); } [PublicAPI] public interface ICommandHandler<in TInput, out TOutput> { TOutput Handle(TInput input); } [PublicAPI] public interface IAsyncCommandHandler<in TInput> : ICommandHandler<TInput, Task> { } [PublicAPI] public interface IAsyncCommandHandler<in TInput, TOutput> : ICommandHandler<TInput, Task<TOutput>> { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のことに同意しました。

1. クエリは常にデータのみを受信しますが、システムの状態は変更しません。 システムを変更するには、次のコマンドを使用します
2. クエリは、ドメインモデルをバイパスして、必要な投影を直線で返すことができます

この場合、 コマンドがない場合、 すべてのQueryは常に同じinputで同じ結果を返します 。 そのような組織は、Queryに戻り結果を変更する可能性のある状態がないため、デバッグを大幅に簡素化します。



必要に応じて、監査ログまたは本格的なイベントソーシングを、基本クラスを介してすべてのコマンドハンドラーに接続できます。

メインのCQRSインターフェースをFunc <T1、T2>およびAction <T>にキャストできることに気付くのは難しくありません。 ステートレスで不変なものを追加すると、 純粋な関数 （hi関数型プログラミング）が得られます。厳密に言えば、ほとんどのクエリはファイルシステム、データベース、またはネットワークで動作するため、これは間違いです。 クエリの結果をキャッシュすることもできますが、データフローと構成可能性を線形化することの利点を得ることができます。

HTTPを介したCQRS

CQRSの原則は、HTTPを介した実装に非常に適しています。 HTTP仕様では、GETリクエストはサーバーからデータを返す必要があることが明確に規定されています。 POST、PUT、PATCH-状態を変更します。 Webプログラミングの優れたフォームは、フォーム送信などのPOST操作を実行した後のGETへのリダイレクトと見なされます。

だから

1. GETはクエリです
2. POST / PUT / PATCH / DELETEはコマンド

一般的に使用される操作の基本クラス

レポートは、データ読み取りの唯一の頻繁なタスクではありません。 一般的な読み取り操作のより一般的な定義は次のとおりです。

1. フィルタリング
2. ページネーション（ページネーション）
3. プロジェクションの作成（クライアント側で必要な形式での集約の表現）

AutoMapperを積極的に使用して、 プロジェクションを構築しています。 このマッパーの際立った機能の1つはQueryable-Extensionsです。これは、RAMにマッピングする代わりに、SQLに変換するためのExpressionを構築する機能です。 これらの投影法は常に正確で効率的ではありませんが、ラピッドプロトタイピングに最適です。



任意のテーブルからデータベースおよびフィルタリングサポートへのページ化された出力の場合、使用できるIQuery実装は1つのみです。

  public class ProjectionQuery<TSpecification, TSource, TDest> : IQuery<TSpecification, IEnumerable<TDest>> , IQuery<TSpecification, int> where TSource : class, IHasId where TDest : class { protected readonly ILinqProvider LinqProvider; protected readonly IProjector Projector; public ProjectionQuery([NotNull] ILinqProvider linqProvier, [NotNull] IProjector projector) { if (linqProvier == null) throw new ArgumentNullException(nameof(linqProvier)); if (projector == null) throw new ArgumentNullException(nameof(projector)); LinqProvider = linqProvier; Projector = projector; } protected virtual IQueryable<TDest> GetQueryable(TSpecification spec) => LinqProvider .GetQueryable<TSource>() .ApplyIfPossible(spec) .Project<TSource, TDest>(Projector) .ApplyIfPossible(spec); public virtual IEnumerable<TDest> Ask(TSpecification specification) => GetQueryable(specification).ToArray(); int IQuery<TSpecification, int>.Ask(TSpecification specification) => GetQueryable(specification).Count(); } public class PagedQuery<TSortKey, TSpec, TEntity, TDto> : ProjectionQuery<TSpec, TEntity, TDto>, IQuery<TSpec, IPagedEnumerable<TDto>> where TEntity : class, IHasId where TDto : class, IHasId where TSpec : IPaging<TDto, TSortKey> { public PagedQuery(ILinqProvider linqProvier, IProjector projector) : base(linqProvier, projector) { } public override IEnumerable<TDto> Ask(TSpec spec) => GetQueryable(spec).Paginate(spec).ToArray(); IPagedEnumerable<TDto> IQuery<TSpec, IPagedEnumerable<TDto>>.Ask(TSpec spec) => GetQueryable(spec).ToPagedEnumerable(spec); public IQuery<TSpec, IPagedEnumerable<TDto>> AsPaged() => this as IQuery<TSpec, IPagedEnumerable<TDto>>; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ApplyIfPossibleメソッドは 、集計または投影のレベルでフィルタリングが実行されているかどうかを確認します（必要な場合など）。 Projectメソッドは、AutoMapperを使用して投影を作成します。



オートフィルターとDynamic Linqは、多くの類似したフォームで作業する場合に役立ちます。

  public static class AutoFilterExtensions { public static IQueryable<T> ApplyDictionary<T>(this IQueryable<T> query , IDictionary<string, object> filters) { foreach (var kv in filters) { query = query.Where(kv.Value is string ? $"{kv.Key}.StartsWith(@0)" : $"{kv.Key}=@0", kv.Value); } return query; } public static IDictionary<string, object> GetFilters(this object o) => o.GetType() .GetTypeInfo() .GetProperties(BindingFlags.Public) .Where(x => x.CanRead) .ToDictionary(k => k.Name, v => v.GetValue(o)); } public class AutoFilter<T> : ILinqSpecification<T> where T: class { public IDictionary<string, object> Filter { get; } public AutoFilter() { Filter = new Dictionary<string, object>(); } public AutoFilter([NotNull] IDictionary<string, object> filter) { if (filter == null) throw new ArgumentNullException(nameof(filter)); Filter = filter; } public IQueryable<T> Apply(IQueryable<T> query) => query.ApplyDictionary(Filter); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

create / editコマンドから集計を構築するには、汎用のTypeConverterを使用できます。



コンテナへの登録を簡素化するために、契約を使用できます 。

おわりに

私たちは職場でイベントソーシングを使用せずにCQRSを積極的に使用しており、これまでのところ印象は非常に良好です。

1. クラスは小さく、1つのことだけを担当することが保証されているため、コードをテストする方が簡単です。
2. 同じ理由で、システムの変更が簡単になります。
3. コミュニケーションが簡素化され、このコードまたはそのコードの場所に関する論争がなくなりました。 さまざまなチームメンバーのコードが統一されました
4. DDDは、初期システムモデリングと集計の作成に使用されます。 対応するテーブルのすべてのメソッドが厳密に最適化されている場合（ORMのバイパスを実装）、集計はまったくインスタンス化されない可能性があります
5. フルバナナでのイベントソーシング-実装は必要ありませんでした。監査ログは非常に頻繁に実装されます。