問題タブ [ddd-service]

ドメインエンティティに適用されるビジネスルールをユーザーが作成できるアプリケーションがあるとします。ルールは、条件と複数のアクションの組み合わせであり、条件が true と評価された場合に対応するアクションが実行されます。このルールはユーザーによって自由形式のテキスト形式で作成され、ルール エンジンが理解して実行できる独自の形式に変換されます。

たとえば、従業員管理システムの場合、従業員が現在の役割で 1 年以上働いており、期待以上の業績を上げているかどうかを確認するビジネス ルールがある場合、10% の昇給で次の役割に昇進できます。このビジネス ルールは、次のようにユーザーが入力できます。

条件: Employee.CurrentRoleLength > 1 && Employee.ExceededExpectations()
アクション: Employee.PromoteToNextRole() | Employee.GiveSalaryIncrement(10)

複数のアクションは|で区切られていることに注意してください。. また、このルールを実行するために、アプリケーションは別のルール エンジン クラス ライブラリを使用して、この条件と両方のアクションを独自の形式 (ルール エンジン クラス ライブラリでも定義されているExecutableScriptなど) に解析します。

次に、DDD を使用してこの要件をモデル化します。次のドメインオブジェクトを思いつきました。

ルール (エンティティ)
条件 (値オブジェクト)
アクション (値オブジェクト)

ここで、ルールは、以下のように条件値オブジェクトとアクション値オブジェクトのリストを含むエンティティです。

上記のドメイン モデルに基づいて、次の質問があります。

1. 外部ルール エンジンに依存せずに条件とアクションを解析して実行するにはどうすればよいですか。ドメイン層は外側の層に依存してはならず、それ自体に限定されるべきであることを理解しています。

2. ドメイン オブジェクトの外部で条件とアクションを解析したとしても、解析された ExceutableScript 値がそれらの内部に存在する必要があり、外部ルール エンジンへの依存が必要です。

3. このシナリオでは DDD が適切なアプローチではなく、間違った方向に進んでいるというだけでしょうか。

長い投稿で申し訳ありません。どんな助けでも大歓迎です。

ありがとう。

ある時点でアカウンティング外部 Web サービスに送信できる請求書集計ルートがあり、そのサービスから取得した ID/番号を保持することで送信済みとしてマークします。

DDDでそれを行う正しい方法はどれですか?

ここに私の考えがあります：

最初のアプローチ:

functionSendToAccountingで請求書の AggregateRoot を作成し、請求書を会計に送信するドメイン サービス/インターフェイスを注入し、会計ソフトウェアで「ID/コード」を取得し、AccountingSoftwareIdプロパティを設定します。

2 番目のアプローチ:

最初のアプローチと同様ですが、ドメイン サービスは次のように永続化する必要があります。

3 番目のアプローチ:

ドメイン サービスは、この動作をカプセル化する責任を完全に負います。

DDD を使用して認証マイクロサービス/ドメインを構築していますが、各サービスがどこに属しているかを特定するのにまだ問題があります。この時点では、認証サービスがドメイン サービスに属しているのか、アプリケーション サービスに属しているのかわかりません。

この動作をドメイン サービスでラップし、アプリケーション サービスを介して応答オブジェクトを公開する必要があります。それとも、アプリケーション サービスとしてそのままにしておく必要があります。

私はシステムに取り組んでおり、node.js で ddd を利用しようとしています。高レベルからのシステムの例を次に示します。

ビジネス ロジックは、患者、または患者の診療科リストのいずれかの診療科のメンバーである医師のみが、自分の医療情報を確認できることを示しています。エンティティにまたがるように見えるため、最初は別のドメインサービスにある必要があると考えていましたが、欠点は、他のサービスが許可サービスを呼び出す必要があることであり、サービスは他のサービスを呼び出すべきではないと考えました。私が実験室と薬物エンティティに配置された場合、私は重複コードであり、完全に違反しています. 部門ドメイン Service に追加すると、サービスが別のサービスを呼び出すことになります。DDD の観点からすると、このようなロジックはどこに属しますか?

DDD の実践に従って、小さな AES 暗号化/復号化 (.NET のラップAesCryptoServiceProvider) を実装しているときに問題が発生しています。

ご覧のとおり、.NETAesCryptoServiceProviderはステートフルです。キーをプロパティとして受け取ります。しかし、私が理解するようになったように、サービスはステートフルであるべきではありません。

1. キーがプロパティであること (たとえば、メソッド パラメータではなく) は、ここでの主な問題ですか?
2. クラスを DDD の方法でどのように実装しますか?
3. 状況によっては、プロバイダーを特定のキーで初期化すると便利で効率的と思われます (そのキーが頻繁に使用される場合)。ステートフル サービスまたは代替サービスを正当化する理由はありますか?

メソッド呼び出しごとに新しい Provider をインスタンス化することもできると思いますが、それは非常に無駄に思えます。無駄を減らすためにキャッシングを実装することもできますが、そうすると全体が過剰に設計されているように感じ始めます。

私が思いついた別の方法は、Aes256CbcCryptorFactory代わりに を作成することです。ファクトリは、実際にはステートフルなCreateCryptor(byte[] key)値オブジェクトを返します。Aes256CbcCryptor消費するサービスは、複数のクリプタ呼び出しを行う必要がある場合、少なくともそのメソッドの 1 つのスコープ内にこのオブジェクトを保持できます。

一方、そのような消費サービスは、値オブジェクトをそのプロパティの 1 つに保存できませんでした。これを行うと、そのサービスがステートフルになるからです。

4. メリットもあるとのことですが、これはやっているということでしょうか？動作のタイプは、値オブジェクトにとって非常に便利に見えますが、少なくとも一時的な状態を持つことができます。

外部データ プロバイダーからデータを読み取るアプリケーション サービス (AppService) とインフラストラクチャ リポジトリ (InfraRepo) があります。AppService は InfraRepo を呼び出し、クライアントにデータを返します。次の要件があります。いくつかのフィルタリング条件とビジネス ロジックがあります。そのために、ドメイン サービス (DomainService) を作成し、InfraRepo 内に挿入しました。外部データ プロバイダー (InfraRepo 内) からデータを取得したら、ドメイン サービスを呼び出し、そこでデータを渡し、結果を取得します。次に、Dto にマップされてクライアントに返されるアプリ サービスに結果を返します。インフラストラクチャ リポジトリ内でドメイン サービスを呼び出すのは正しいですか。