1

この質問はアーキテクチャ/デザインに関するものです:

x 個のタスクを実行する必要があるコンシューマーがいます。コンシューマーを小さなタスクに分割したり、小さなタスクを独自のコンシューマーに追加したりすることはいつ考えるべきですか?

例：

消費者 FooBarShipping は

  • レポート用のデータベース エントリを追加します
  • アカウントのデータベース エントリを追加します
  • 配送用のデータベース エントリを追加します
  • 出荷請求書を生成します (必要に応じて PDF またはその他の形式)
  • 出荷通知を作成します
  • アカウントの通知を作成します

だから私の質問は、箇条書きをより小さな消費者に分割するのはいつですか? コンシューマーはそのままで問題なく動作しますが、大きくなりすぎているため、より小さく、より管理しやすいプロセスにリファクタリングする必要があると感じています。

各箇条書きはそれ自身の消費者であるべきですか? それらを 3 つのコンシューマーに分割することがわかります

  • データベース
  • pdf (ドキュメント)
  • 通知

しかし、消費者が行うべき作業の最小単位は何でしょうか? SQL ステートメントを実行するためにコンシューマーが本当に必要ですか?

私は見た

私にとって、消費者は他の基本的なタスクを開始する基本的なタスクを実行するように見えます。

4

1 に答える 1

1

一般的なアーキテクチャの場合、6 つのモジュールがあり、それぞれを次のようにグループ化する必要があります。

  • 1 レポート用のデータベース エントリを追加します
  • 1 アカウントのデータベース エントリを追加します
  • 1 出荷用のデータベース エントリを追加します
  • 2 発送請求書を生成します (必要に応じて PDF またはその他の形式)
  • 3 出荷通知を作成する
  • 3 アカウントの通知を作成します

リポジトリ パターンを実装する場合、グループ 1 は 3 つのリポジトリに分割する必要があります。各リポジトリは各エンティティ (レポート、アカウント、配送) を処理します。ただし、挿入、更新、削除、および選択操作を提供できます。

グループ 3 と同様に、一般的な通知オブジェクト (私の用語ではクラス) は、x、y、z エンティティ通知に成長する可能性があるため、良いことではないと思います。

しかし、心配しないでください。あなたはすでに正しい道を歩んでいます。依存関係、コンストラクター注入について言えば、3 つのオブジェクトに分けるとよいでしょう。FooBarShipping 発送方法の一般的な考え方:

FooBarShipping.Ship(Invoice inv){
    invoiceRepository.InsertNew(inv);
    invoiceGenerator.GenerateInvoice(inv);
    invoiceNotification.Notify(inv);
}

InvoiceRepository.InsertNew の一般的な考え方:

InvoiceRepository.InsertNew(Invoice inv){
    reportingRepository.InsertNew(inv.Reporting);
    accountRepository.InsertNew(inv.Account);
    shippingRepository.InsertNew(inv.Shipping);
}

InvoiceNotification.Notify と同じ考え方:

InvoiceNotification.Notify(Invoice inv){
    shippingNotification.Notify(inv);
    accoountNotification.Notify(inv);
}

ただし、データ構造と実装に関して調整が必要になる場合があります。しかし、それは一般的な考えです。ただし、この記事 (集約サービスへのリファクタリング)を参照することもできます。

于 2013-05-15T12:39:04.340 に答える