費用対効果の高いコード2：身をかがめるDDD、潜むCQRS

3人のプログラマーがフィールドを横断し、反対側の家に着くように頼まれました。 初心者プログラマーは短い距離を見て、「これはそう遠くない！ 10分かかります。」 経験豊富なプログラマーがこの分野を見て、しばらく考えて、「1日でそこに着くことができる」と言った。 新人は驚いて彼を見た。 ソフトウェアの第一人者はその分野を見て言った。 「10分ほどですが、15分で十分だと思います。」 経験豊富なプログラマが笑った。

初心者プログラマーは出発しましたが、数分以内に地雷が爆発し始め、大きなピットを残しました。 爆発から、彼は戻って飛んだ、そして彼は最初からやり直さなければならなかった。 目標を達成するのに2日かかりました。 さらに、彼は至る所で揺れ、到着したときに負傷しました。

経験豊富なプログラマーが四つんcいをしました。 地面を優しく手探りし、鉱山を探して、安全だと確信した場合にのみ移動しました。 ゆっくりと注意深く彼は日中に畑を渡った。 数分たっただけです。

プログラマーの第一人者は出発し、フィールドをまっすぐに行きました。 意図的かつ直接的。 彼はわずか10分で目標を達成しました。
「これをどのように管理しましたか？」他の2人に尋ねました、「どうやって単一の鉱山を引っ掛けないようにしたのですか？」
「簡単」と彼は答えた。 「私の道に地雷を敷きませんでした。」

残念ながら、私は認めざるを得ません-私たちは自分の地雷を敷設しています。 最初の部分では、ソフトウェア開発の主なリスクを詳細に調べ、これらのリスクを軽減する技術的および方法論的な方法について説明しました。 過去1年間、私は多くのコメントを受け取りました。その主な意味は次のとおりでした：「すべてがクールですが、どこから始めて、実際の世界でどのように見えるか。」 実際、最初のテキストはより理論的な性質のものであり、リンクのカタログを表しています。 この記事では、できるだけ多くの例を示します。

十分な経験がないプログラマーの場合、 最初の記事で説明した問題の多くは、長い目で見ただけで理解できない可能性があります。10ページにサイトを記述する方法と、フィルタリング用のいくつかのフォームとCRUD管理パネルに大きな違いはありませんすべてのコードは数日でゼロから書き直すことができます。 しかし、1年半か2年で何が起こるでしょうか？

私たちのサイトは開発を開始し、新しい機能が登場し、すでに数十のページとフォームがあり、外部リソースとのアフィリエイトプログラムが追加されています。 大富豪「Vkontakte」に広告を出し、ロード中にメインページを「開発」しました。 関係ありません、キャッシュにとどまります。 今、あなたはすぐにフレンドリーなサービスと提携する必要があります。 コードベースからパートナーと統合コードをコピーして貼り付け、「私たちの」データと「外部の」データを同期するためのファイルを作成します。

変更はビジネスルールで始まり、ストレージのコードとサブジェクトエリアで複製する必要があり、メインページのキャッシュを定期的に更新する必要があり、バックログのバグと構成の問題の数が増えています。
ビジネスルールの変更、統合、パフォーマンスの最適化、機能の拡張を6〜7回繰り返し、スタックオーバーフロー、パートナーのSDKコード、松葉杖、ホットパッチ、さまざまな非常に役立つサードパーティのコンポーネント、および独自の自転車からなるサンプルコードからフランケンシュタインモンスターを作成しました。

2-3年前のコードで修正しなければならない主な問題

1. 定型コードの繰り返し（使用、try-catch、logなど）：コードベースの変更や修正が困難になり、同じ構成を書くのに静かに時間がかかります（プロジェクトの最初の数秒、1年または2日後）コードベースの存在）
2. 同じEntity、DTO、およびViewModelクラスの暗黙的で思いやりのない作成、Linqクエリの複製、同じタイプのITEntityRepositoryの作成を含むコードの重複：実装が1つしかないIRepository <TEntity>インターフェイス
3. SRPの違反：異なるコンテキストからのエンティティプロパティの詰め込み、ドメインモデルとは関係なく、さまざまなマネージャー、サービス、ヘルパーを明確な責任で作成する
4. LSP違反
5. NullReferenceException
6. データエラー
7. フィードバックの作成、アプリケーションレイヤー、インフラストラクチャコード、ドメインモデルコードの混合

通常、このすべての怒りの正当化は次のとおりです。

1. タイトなリリース日
2. リファクタリングする時間がない
3. 計画と設計の時間不足（どのアーキテクチャですか？

一般に、これはすべて真実ですが、経験豊富な開発者でさえ、適切な決定を迅速に下すのに十分な「マット部分」がないことが多いことを認めなければなりません。 「本当」ということで、私は次の状況を理解しています：80％の場合、ビジネスケースを実行するコードを記述し、20％の場合、特定の20％を記述する必要がある（つまり、要件がどのように変化するか）を推測するたびに、少し先を行っています。 利害関係者が望むもの（アプリケーションのドメインモデルがどのように変化するか）を推測するには、通常、管理作業の経験および/またはサブジェクトエリアの経験が必要です。

ただし、多くの成長中のプロジェクトで発生する多くの要件があります。

1. マルチユーザーアクセス（悪名高いhabr効果）、ビュー、いいね！などのカウント
2. 分析とパーソナライゼーション（販売ファネルの構築、より関連性の高いコンテンツを提供するためのユーザー設定の分析）
3. 全文検索
4. スケジュールされたタスクとスケジュールされたタスク
5. データのフィルタリング、変換、およびページング
6. ロギング、通知システム、監視、自己診断、障害およびエラー処理後の自己回復

この記事では、アプリケーションインフラストラクチャからドメイン（ビジネスルール）を分離することに焦点を当てます。 すべてのAOP、動的コンパイル、およびその他の魔法は次回に残されます。

10のアプリケーション層ですべての人に十分なはずです

「真空中の通常のWebアプリケーション」の場合、最大10層をカウントしました。 それはたくさんですか、それとも少しですか？ 「コーナーをカット」して古典的な3つでうまくいくことができるとすれば、それはちょうどいいと思います。 エンドポイント、データマッパー、パブリッシャーサブスクライバー、イントレセプターを推奨します。 残り：

1. サービス
2. コマンド/クエリ
3. エンティティ
4. DAO

すべてを適切な場所に配置するために、Webアプリケーションの最も単純なケースであるランディングページから始めましょう。

ランディングページ（たとえば、「ランディングページ」）-特定の方法で構築されたWebページ。その主なタスクは、対象ユーザーの連絡先情報を収集することです。 広告の効果を高め、視聴者を増やすために使用されます...

1ページあり、「リード」を収集します。 リードにはメールが必要です。 フォームのオプションのフィールドは、電話番号と名前です。 クラス「lead」を作成しましょう：

public interface IEntity { string GetId(); } public class Lead : IEntity { public static Expression<Func<Lead, bool>> ProcessedRule = x => x.Processed; private string _email; [Key, Required, Index("IX_Email", 1, IsUnique = true)] public string Email { get { return _email; } set { if (string.IsNullOrEmpty(value)) { throw new ArgumentNullException("email"); } _email = value; } } public string Phone { get; set; } public bool Processed { get; set; } public DateTime CreatedDate { get; set; } [Obsolete("Only for model binders and EF, don't use it in your code", true)] internal Lead() { } public Lead([NotNull] string email, string phone = null) { Email = email; Phone = phone; CreatedDate = DateTime.Now; } public bool IsProcessed() { return this.Is(ProcessedRule); } public string GetId() { return Email; } } 

エンティティ、リッチドメインモデル、および防御プログラミング（別名カプセル化）

論争： samolisov.blogspot.ru/2012/10/anemic-domain-model.html
私はリッチドメインモデル（リッチドメインモデル）の支持者であり、貧血が好きではないため、Leadは適切なコンストラクターを持ち、矛盾した状態（不変条件に違反）に陥ることを許可しません。 祖先が貧血モデルを生み出した現代のORMフレームワークにより、カプセル化の原理を観察することができます（ほとんど）。 内部アクセス修飾子が役立ちます。 特に、手を洗わず、デフォルトでコンストラクターを使用しないユーザーには、ドメインアセンブリ内に[Obsolete]属性があります。 2番目のパラメーターは、このコンストラクターを明示的に使用しようとするとビルドを中断しますが、ORMとModelBinderはこのコンストラクターを冷静に使用します。

  [Obsolete("Only for model binders and EF, don't use it in your code", true)] internal Lead() { } public Lead([NotNull] string email, string phone = null) { Email = email; Phone = phone; CreatedDate = DateTime.Now; } 

ジュニアがそれを削除しないという保証はありませんが、そのようなことはコードレビュー中に解決できます。

.NETのプロパティは、データベースにマップするためだけでなく、発明されました。 このようなコードの編成により、データベースに保存するときではなく、間違った電子メールを設定しようとする場所に正確に収まります。これは、値が設定された瞬間から、特に大規模な操作中に非常に遠いことがあります。

  [Key, Required, Index("IX_Email", 1, IsUnique = true)] public string Email { get { return _email; } set { if (string.IsNullOrEmpty(value)) { throw new ArgumentNullException("email"); } _email = value; } } 

コンストラクターはEmailプロパティも使用するため、不変式は確実に保護されます。
この方法で作業する方が簡単なので、ルール-コードファースト。 まず、ドメインモデルを作成し、次に自動移行を作成し（したがって、Entity Frameworkを使用）、実行します。

私の観点からすると、パラメーターのないコンストラクターへのアクセスをpublic（public）に置き換えて、同じタイプの不要なDTOとViewModelを作成せずにこのように記述することは恥ずべきことではありません。

  [HttpPost] public ActionResult Index(Lead lead) { if (!ModelState.IsValid) { return View(lead); } //… } 

条件の下で：

1. リードクラスは集約のルートではありません
2. アプリケーションフォームには、リードクラスと1対1のマッピングがあります。
3. パラメーターなしのコンストラクターは、Obsolete属性によって保護されています

それ以外の場合は、DTOおよび/またはViewModelを作成し、DataMapperを使用します。

たぶんモナド

Visual Studio 2015がCTPに新しい演算子を残す限り、このモナドはコードを読みやすくするのに役立ちます。 R＃のエラーとして、JetBrains.AnnotationsおよびNullReferenceExceptionの可能性と組み合わせてMaybeを使用すると、コードにNullReferenceExceptionが存在しないことが保証されます。 実際、これはNullObjectパターンの機能的なスタイルの実装です。

ビジネスロジックとインフラストラクチャ（DDD）の分離

DDDをめぐる主な論争は、次の点を中心に展開されます。

1. ネットワーク上のDDDで公開されているアクセス可能な例が少なすぎるため、それが何であるかは明確ではありません
2. ドメインと見なされるものとインフラストラクチャとは何ですか
3. DDD-op-op、ready code方法論と比較して非常に長く高価です

Evansの本を読むことは、 The Art of Unit Testingに続いて、コードを理解する上で私にとって2番目の急転でした。 ソフトウェア開発の10年間、私は十分な数のコードベースを十分に得ることができました。 ありがたいことに、すべてのプログラミング言語にはすでに基本的なプラットフォーム（フレームワーク）とパッケージマネージャーがあり、ブラックジャックと遊女でMVCフレームワークを記述することは誰にも起こりません。

ただし、ビジネスロジックは、アプリケーション内のさまざまな場所（ストアドプロシージャ、ヘルパー、マネージャー、サービス、コントローラー本体、リポジトリ、linqクエリ）で見つけることができます。 明確な規制がない場合、各開発者は、美しいものについてのアイデアに従ってビジネスロジックを編成します。

これは問題の全体を作成します：

1. ビジネスルールを探す場所が明確ではない
2. ドメインモデルコードのテストカバレッジとは何かという質問に明確に答えることは不可能です。
3. コードは手続き型スタイルに引き寄せられ、カプセル化は壊れています
4. 2か所以上でビジネスルールを複製する危険があります（たとえば、c＃コードとストアドプロシージャコード。要件が変更された場合、1か所のみでルールが変更される可能性があります。その結果、差異は残り、数か月後に発生する可能性があります。他の人は問題になりますが、それがどのように「正しくあるべきか」を知っているという事実ではありません。さらに、マネージャーとヘルパーは不明確な責任を持つクラスであり、高い確率で時間とともに神のオブジェクトに変わります
5. アセンブリ間の依存関係は一切規制されていません。 ジュニアの軽量ドメインモデルクラスは、WebコンテキストとCommon.Webのアセンブリに簡単に依存し始めることができます。

より高いレベルでは、これは次のように変換されます。

1. フルタイムチーム全体がバグのサポートとバグの除去に忙しい状態まで、開発のペースを遅くする
2. 絶え間ないバグ修正と松葉杖
3. アプリケーションデータベースのエラーをサポートおよび排除するために追加のリソースを割り当てる必要がある

私にとって、Evans DDDはビジネスロジックで作業を標準化する方法です。 DDDは、このための一連のパターンを提供します。 主なものを見てみましょう。 同時に、別の「ファッショナブルな」コンセプトである「CQRS」と「結婚」します。

これはDDDとどのように関連していますか？

DDDは、ドメインが別個であり、インフラストラクチャが別個であることを示しています。 さて、「エンティティ」があります。

エンティティ

  public interface IEntity { string GetId(); } 

エンティティは、一意の識別子を持つものです。 袋の中の2本の釘はエンティティではありません。なぜなら、あなたは一方を他方と区別できないからです。 ドメインに関しては、それらは同一です。 しかし、私たちの税のためのVasyaとPetya-エンティティ。 納税者番号（TIN）があります。

最新のアプリケーションでは、最も一般的に使用されるIDは自動インクリメント整数値またはGUIDです。 このアプローチの普及にもかかわらず、場合によっては、特別な処理を必要とする状況を作り出すことができます。 航空会社のチケットをアグリゲーターから購入したことがある場合、アグリゲーターの予約番号は航空会社の予約番号と一致しないことがあります。 これは、キャリアが独自のITシステムを持ち、アグリゲーターが独自のシステムを持っているという事実によるものです。

ランディングページに戻って、サンプルをリードしましょう。 IEntityの最も抽象的な実装は、IDを文字列として返すメソッドです。 私は意図的にプロパティではなくメソッドを使用します。 Leadクラスのすべてのプロパティは、データベースフィールドにマップされます。 これにより、あいまいさを避け、マッピングを覗く必要がなくなります。 主キーは、IDではなく電子メールです。 Idプロパティを実装した場合、IdプロパティがデータベースのEmailフィールドにマップされていることを明示的に示す必要があります。さらに、これにより他のタイプ（整数とGUID）の主キーに問題が発生します

  public class Lead : IEntity { private string _email; [Key, Required, Index("IX_Email", 1, IsUnique = true)] public string Email { get { return _email; } set { if (string.IsNullOrEmpty(value)) { throw new ArgumentNullException("value"); } _email = value; } } public string Phone { get; set; } public bool Processed { get; set; } public DateTime CreatedDate { get; set; } // IEntity Implementation public string GetId() { return Email; } 

ORM Entity Frameworkをメインとして使用することは既に述べましたが、それだけではありません。 主な理由：

1. 移行の自動生成（多くの時間を節約し、ルーチンコードを記述する必要がありません）
2. .NETでの最高のlinqサポート
3. NHibernateより速く開発
4. データのマッピングと移行の作成のためのDataAnnotation属性をサポート

流entなマッピングVS Atributeマッピング

もちろん、すべてのマーカーの味と色は異なります。 流mappingなマッピングはよりクリーンであり、ドメインアセンブリに応じてEFをドラッグすることはできませんが、その冗長性と2つのクラスをサポートする必要性が好きではありません：エンティティとマッピング。 これはSRP違反であると誰かが言うかもしれません。 私の意見では、属性は必須のコードではなく、そのような比較は正しくありません。 記録の形式とEFへの余分な依存だけに違いが見られますが、必要に応じて簡単に切り取ることができます。

永続性の無知

そのため、ドメインエンティティがあり、データソースからデータを作成、処理、保存、フィルタリング、取得、削除する必要があります。 一般の人々では、これはCRUD操作と呼ばれます。 オブジェクトの不変式に違反しない「正しい」コンストラクタを使用する必要があることを忘れずに、new演算子を使用してエンティティを作成できます。 ORMサポートのためにのみデフォルトコンストラクタを宣言し、[Obsolete]属性を使用して汚れた手から自分自身を保護しました。

オブジェクトを保存してデータソースから取得するにはどうすればよいですか？ 最新のフレームワークでは、アクティブレコード（AR）と作業単位（UoW）の2つのアプローチが使用されます。 私はActive Recordの強敵です。 解釈されたPLではARが利点を与える可能性がありますが、コンパイルされたPLではそうではありません。 ARは最もRPい方法でSRPに違反し、Saveメソッドをすべてのエンティティに追加します。 エンティティのタスクは、データベースに自身を保存するのではなく、ビジネスロジックを実装し、データをカプセル化することです。 したがって、私の選択はすごいです。

  public interface IUnitOfWork: IDisposable { void Commit(); void Save<TEntity>(TEntity entity) where TEntity : class, IEntity; void Delete<TEntity>(TEntity entity) where TEntity : class, IEntity; } 

EFの場合、UoW実装はアプリケーションのDataContextになります。 ただし、DataContext自体はドメインアセンブリに固執しません。 まず、なぜここでEFに依存する必要があるのですか？ 次に、多くの場合、開発チームを分離するために境界コンテキストを実装する必要がありますが、データ回線の同期解除のオプションを除外するには、同じDataContext内に移行を残す方が良いです。

保存、編集、削除の方法は明確です。 データを取得する機能は残ります。 従来、この機能はリポジトリを使用して実装されていました。 そして伝統的に「不器用に」実装されました。 問題については、「 問題のあるリポジトリテンプレート 」の記事で詳しく説明しています 。

要するに、最初にこれを行います：

 public interface IRepository<T> { T GetById(int id); IEnumerable<T> GetAll(); bool Add(T entity); bool Remove(T entity); } 

結果は次のとおりです。

 class AccountRepository : IRepository<Account> { public Account GetByName(string name); public Account GetByEmail(string email); public Account GetByAge(int age); public Account GetByNameAndEmail(string name, string email); public Account GetByNameOrEmail(string name, string email); // ... public Account GetByAreYouFuckingKiddingMe(SomeCriteria c); } 

このような状況を終了します（以下に説明する理由により、拡張メソッドを使用したオプションは考慮しません）。

 public interface IRepository<T> { T GetById(int id); //   IQueryable<T> Query(); bool Add(T entity); bool Remove(T entity); } 

ただし、次のように中断します。

 //   - repo.Query().Where(a => a.IsDeleted = false); //   ,        repo.Query().Where(a => a.IsDeleted = false && a.Balance > 0); // runtime error repo.Query().Where(a => a.CreationDate < getCurrentDate()); 

最後の例では、最初の2つのlinqクエリは、アクティブアカウントビジネスルールの変更を示しています。 最初は、削除されていないものがアクティブであると見なし、「バランスはゼロより大きくなければならない」という要件が追加されました。 linqクエリは非常に簡単に記述できるため、コードベースの数十箇所にコピーされます。 ほとんど確実にどこかでそれを変更しますが、どこかでそれを忘れます。

3番目の例は正常にコンパイルされますが、ORMはgetCurrentDate関数をSQLに変換する方法を理解していないため、実行時にクラッシュします。 時間がなくなり、タスクが後輩に届いた場合、彼はすぐに次のようなファイルでコードを「仕上げ」ます。

 repo.Query().ToEnumerable().Where(a => a.CreationDate < getCurrentDate()); 

また、300万のアカウントはすべてRAMに格納されます。

IQueryableを出力することにはまだ暗黙的な問題があります。

1. IQueryableがリークしており、 明らかにLSPに違反しています。 フィードする式を「ダイジェスト」するIQueryable実装は、メモリ内のみです。 ただし、メモリ内にはlinq2objectがあるため、IQueryableは無意味になります。 Whereリクエストは、コードの潜在的な障害ポイントです。
2. すべてのデータソースがlinqをサポートしているわけではありません。 ある時点で、フルテキスト検索が必要になり、それを使用してSphinxまたはElasticが必要になります。 「linq-providerを書きましょう」という提案が経営陣からの応答を見つけることを疑います（そして、ちなみに正しく）。 問題はフルテキストに限定されず、データはネットワークを経由してディスクに保存され、クラウドファイルシステムに保存されます。
3. データベースがデータソースとして機能する場合でも、パフォーマンスの目的で、データの一部が非正規化された形式であるか、NOSQLソリューションに転送される可能性があります。 クエリを手で書いて、すべてを最大限に調整する必要がある可能性があります。 マッピングオブジェクト

最初の問題は原則として解決されません。 これは、linqの設計により設計されています。 文句を言うのは罪です。linqはとても便利です。 項目2および3は、実際にはIQueryableがすべての場面で抽象化として適切ではないことを示唆しています。なぜなら、実際の世界では、すべての.NET開発者がハーフキックで式ツリーを解析して、任意のデータソースに。
みんながすでに私たちのために来てくれてうれしいです

仕様別名フィルター

 public interface ISpecification<in T> where T:IEntity { bool IsSatisfiedBy(T o); } public interface IRepository<T> { T GetById(int id); //   IEnumerable<T> GetBySpecification(ISpecification<T> spec); bool Add(T entity); bool Remove(T entity); } 

仕様はビジネスフィルタリングルールです。 オブジェクトが条件を満たしているかどうかを示すメソッドは1つだけです。 現在の形式では、仕様はコードの重複の問題を解決します。Linqがなく、各フィルタリングルールに対して独自の仕様クラスを記述する必要があります。

しかし、すみません、なぜこれが必要なのですか？ IsSatisfiedByをSQLに変換することはできません。つまり、データベースからすべてのレコードを再度取得し、それらでフィルタリングする必要があります。 ここで、くしゃみごとに仕様を作成する必要があります。これは、（特定の方法でデータをフィルタリングする必要があるインターフェースの代わりに）一度だけ使用される多くのクラスを作成することを意味します。
実際、全体の議論が進行中であり、 「仕様」のパターンはlinqの出現により時代遅れになったと彼らは言います 。
建築宇宙飛行士が最初に提供することは次のとおりです。

 public interface IExpressionSpecification<T> : ISpecification<T> where T:class,IEntity { Expression<Func<T, bool>> Expression { get; } } public interface IRepository<T> { T GetById(int id); //   IEnumerable<T> GetBySpecification(IExpressionSpecification<T> spec); bool Add(T entity); bool Remove(T entity); } 

同じ卵、仕様の形で追加の不必要なレイヤーを持つプロファイルビューを表示するために、スーパーパワーを持つ必要はありません。 さらに、コード内のlinqクエリの重複の問題は、次のようにエレガントに解決できます。

 public class Account : IEntity { [BusinessRule] public static Expression<Func<Lead, bool>> ActiveRule = x => x.IsDeleted && x.Ballance > 0; } 

最後に

1. リポジトリは、すべてのデータソースの基本的な抽象化として効果的に使用することはできません
2. linqは非常に便利ですが、経済的な理由やパフォーマンスの制限のためにどこにも適していません

CQ [R] S-コマンド、クエリ[責任]分離

または、ロシア語での読み取りと書き込みの分離。 原則は、ロードされたシステムで最大のアプリケーションを見つけました。 古典的な例は、ソーシャルネットワーク上のフィードです。すべての友人のテーブルの山からデータを取得する必要があり、誰もがあなたの写真をどのように気に入って再投稿するかを考慮することを忘れないでください。 従来の実装はこのタスクには適していません-結合と読み取り/書き込みロックが多すぎます。
一般的な解決策は、読み取りと書き込みを分離してブロッキングを回避することです。 デノロマイゼーション戦略は異なる場合がありますが、主なポイントは次のとおりです。

1. 結合を取り除き、フラットデータを読み取ります
2. 読み取り/書き込みロックを回避する
3. 「バックグラウンドで」データを同期し、変更を蓄積する

したがって、クラシックリポジトリは、コマンドとクエリの2つのインターフェイスに分かれています。
コマンドは追加、変更、および削除を実装し、クエリはデータの読み取りを実装します。

  public interface IQuery<TEntity, in TSpecification> where TEntity : class, IEntity where TSpecification : ISpecification<TEntity> { IQuery<TEntity, TSpecification> Where([NotNull] TSpecification specification); IQuery<TEntity, TSpecification> OrderBy<TProperty>( [NotNull] Expression<Func<TEntity, TProperty>> expression, SortOrder sortOrder = SortOrder.Asc); IQuery<TEntity, TSpecification> Include<TProperty>([NotNull] Expression<Func<TEntity, TProperty>> expression); [NotNull] TEntity Single(); [CanBeNull] TEntity FirstOrDefault(); [NotNull] IEnumerable<TEntity> All(); [NotNull] IPagedEnumerable<TEntity> Paged(int pageNumber, int take); long Count(); } public interface ICommand { void Execute(); } public interface ICommand<in T> { void Execute(T context); } public interface IPagedEnumerable<out T> : IEnumerable<T> { long TotalCount { get; } } public class CreateEntityCommand<T> : UnitOfWorkScopeCommand<T> where T: class, IEntity { public override void Execute(T context) { UnitOfWorkScope.GetFromScope().Save(context); UnitOfWorkScope.GetFromScope().Commit(); } public CreateEntityCommand([NotNull] IScope<IUnitOfWork> unitOfWorkScope) : base(unitOfWorkScope) { } } public class DeleteEntityCommand<T> : UnitOfWorkScopeCommand<T> where T: class, IEntity { public DeleteEntityCommand([NotNull] IScope<IUnitOfWork> unitOfWorkScope) : base(unitOfWorkScope) { } public override void Execute(T context) { UnitOfWorkScope.GetFromScope().Delete(context); UnitOfWorkScope.GetFromScope().Commit(); } } 

クエリの主な役割は、仕様（ドメインフィルタルール）をデータソース（インフラストラクチャ）のクエリに変換することです。 クエリはデータソースからの抽象化を提供します-データの取得元は関係なく、仕様はlinq +の一種です。 linqをサポートするデータソースの場合、ExpressionSpecificationを使用できます。 linqの使用が困難な場合（Elastic Searchの場合のようにプロバイダーが存在しない場合など）、式をスローして仕様を使用します。

  public interface IExpressionSpecification<T> : ISpecification<T> where T:class,IEntity { Expression<Func<T, bool>> Expression { get; } } public static IQuery<TEntity, IExpressionSpecification<TEntity>> Where<TEntity>( this IQuery<TEntity, IExpressionSpecification<TEntity>> query, Expression<Func<TEntity, bool>> expression) where TEntity : class, IEntity { return query.Where(new ExpressionSpecification<TEntity>(expression)); } 

仕様のインスタンスを使用して、RAM内のデータをフィルター処理し、仕様をクエリに変換して、データソースへのクエリをクエリに依存させることができます。

ICommandFactory、IQueryFactory

多数の小さなコマンドおよびクエリオブジェクトの作成は退屈な作業になる可能性があります。慣例に従ってIOCコンテナに登録するのは論理的です。 コンテナをすべてのアセンブリにドラッグせず、ServiceLocatorを作成しないために、この責任をファクトリに割り当てます。

  public interface ICommandFactory { TCommand GetCommand<TEntity, TCommand>() where TCommand : ICommand<TEntity>; T GetCommand<T>() where T : ICommand; CreateEntityCommand<T> GetCreateCommand<T>() where T : class, IEntity; DeleteEntityCommand<T> GetDeleteCommand<T>() where T : class, IEntity; } public interface IQueryFactory { IQuery<TEntity, IExpressionSpecification<TEntity>> GetQuery<TEntity>() where TEntity : class, IEntity; IQuery<TEntity, TSpecification> GetQuery<TEntity, TSpecification>() where TEntity : class, IEntity where TSpecification : ISpecification<TEntity>; TQuery GetQuery<TEntity, TSpecification, TQuery>() where TEntity : class, IEntity where TSpecification: ISpecification<TEntity> where TQuery : IQuery<TEntity, TSpecification>; } 

次に、クエリの操作は次のようになります

 _queryFactory.GetQuery<Product>() .Where(Product.ActiveRule) //   ,     Account.  ExpressionSpecification .OrderBy(x => x.Id) .Paged(0, 10) //  10     //        ElasticSearch,  : _queryFactory.GetQuery<Product, FullTextSpecification>() .Where(new FullTextSpecification(«»)) .All() //  EF          Dapper _queryFactory.GetQuery<Product, DictionarySpecification, DapperQuery>() .Where(new DictionarySpecification (someDirctionary)) .All() 

すべての場合で、同じコードを使用し、_queryFactory.GetQuery <Product、DictionarySpecification、DapperQuery>（）構造は、これが最適化であることを明示的に示しています。この行は、進化のリファクタリング中にのみコードに表示されました。これは、最初は開発速度のためにORMで記述したためです。チーム内に式ツリーに精通している人がいる場合、すべての要求を徐々にlinqに翻訳できます（実際の生活では、経済的な理由からこれはほとんど不可能です）。

_queryFactory.GetQuery <Product、FullTextSpecification>（）の場合、「フルテキスト仕様」を指定しますが、ドメインコードは返されたインスタンス（ElasticSearchQuery）について何も知りません。彼にとって、これは単なる全文検索フィルタリングルールです。

論争：habrahabr.ru/post/125720

少し構文糖

例に戻ります。

 public class Account : IEntity { [BusinessRule] public static Expression<Func<Lead, bool>> ActiveRule = x => x.IsDeleted && x.Ballance > 0; bool IsActive() { //     ??? } } 

「アクティブアカウント」ビジネスルールは論理的な場所に配置され、再利用されます。プロジェクト全体に散在するラムダを怖がる必要はありません。
この要件は、Expression <Func <Lead、bool >>の形式で必要になる場合があります-データソースへのクエリへの変換のために必要な場合があります。すべての人のために仕様クラスを作成することは、良いアイデアとは思えません。次の実装をいつ使用できますか？

  public static class Extensions { private static readonly ConcurrentDictionary<Expression, object> _cachedFunctions = new ConcurrentDictionary<Expression, object>(); public static Func<TEntity, bool> AsFunc<TEntity>(this object entity, Expression<Func<TEntity, bool>> expr) where TEntity: class, IEntity { //@see http://sergeyteplyakov.blogspot.ru/2015/06/lazy-trick-with-concurrentdictionary.html return (Func<TEntity, bool>)_cache.GetOrAdd(expr, id => new Lazy<object>( () => _cache.GetOrAdd(id, expr.Compile()))); } public static bool Is<TEntity>(this TEntity entity, Expression<Func<TEntity, bool>> expr) where TEntity: class, IEntity { return AsFunc(entity, expr).Invoke(entity); } public static IQuery<TEntity, IExpressionSpecification<TEntity>> Where<TEntity>( this IQuery<TEntity, IExpressionSpecification<TEntity>> query, Expression<Func<TEntity, bool>> expression) where TEntity : class, IEntity { return query .Where(new ExpressionSpecification<TEntity>(expression)); } } public class ExpressionSpecification<T> : IExpressionSpecification<T> where T:class,IEntity { public Expression<Func<T, bool>> Expression { get; private set; } private Func<T, bool> _func; private Func<T, bool> Func { get { return this.AsFunc(Expression); } } public ExpressionSpecification([NotNull] Expression<Func<T, bool>> expression) { if (expression == null) throw new ArgumentNullException("expression"); Expression = expression; } public bool IsSatisfiedBy(T o) { return Func(o); } } public class Account : IEntity { [BusinessRule] public static Expression<Func<Lead, bool>> ActiveRule = x => x.IsDeleted && x.Ballance > 0; bool IsActive() { this.Is(ActiveRule); } } 

サービス、マネージャー、ヘルパーはどこにいますか？

コードが適切に編成されていれば、ドメインにhelper'ovはありません。プレゼンテーション層に何かがあるのか​​もしれません。 ManagerとServiceは同じものなので、Managerという名前をまったく使用しない方が良いでしょう。サービスは純粋に技術的な用語です。 Serviceを接尾辞としてのみ使用するか、まったく使用しません（IOCの同意により登録するために名前空間のみを残します）。

実際のビジネスには「サービス」はなく、「キャッシュデスク」、「ポスティング」、「クォータ」などがあります。そのため、アプリケーションドメインに従ってビジネスロジックと名前クラスをグループ化し、必要な場合にのみ作成することをお勧めします。 CRUD操作にサービスは必要ありません。 UoW + Command + Query + Specification + Validatorのバンドルは、会計システムのニーズの90％をカバーするのに十分です。ちなみに、これには1つのコントローラークラスのみが必要です。

おわりに

そのようなアーキテクチャは過負荷に見えるかもしれません。実際、このようなアプローチには特定の制限があります。

1. 開発者の資格：プログラミングパターンの理解とプラットフォームの十分な知識が必要です。
2. インフラストラクチャコードへの初期投資（プロジェクトからインターフェイスを取得し、不要な依存関係を解き、インフラストラクチャをできるだけ抽象的で軽量にするためにフルタイムでほぼ4日かかりました。
3. 実際のプロジェクトでテストに合格しているのはこのアセンブリであり、メトリックはなく、このアプローチが標準化によるパフォーマンスの向上を保証することを保証します（主観的には、これは100％確信しています）

メリット

1. インフラストラクチャからのドメインの明確な分離
2. , , , , ,
3. -
4. repair-kit
5. ,

継続するには...