domain-driven-design - オブジェクトのインスタンス化 - ポリモーフィズム

Question

「債券」を処理する金融アプリケーションがあります。する必要がある

貧血モデルを回避するためにアプリケーションをモデル化します (これは悪いことだと理解しています)。
結合のタイプに応じて、さまざまな実装をインスタンス化します。

システムは外部システムから命令を取得し、その命令を指定された結合に適用します。したがって、私は命令エンティティを持っています

Instruction[Id,BondReference,Action,Value]

例えば、債券で可決された決議に「賛成」票を投じる指示の場合

Instruction
{
    BondReference: Bond1,
    Action: Vote
    Value: VoteYes
    ResolutionReference: Resolution1
}

および債券エンティティ

Bond
{
    Id: 1,
    Reference: Bond1
    Resolutions: [
                     {Resolution1: We have resolved to increase our stake in Google},
                     {Resolution2: We have resolved to fire the CEO}
                     ...
                 ]
    Instructions: [Inst1,Inst2,Inst3...]
}

ただし、命令は通常、1 つ以上のことを行います (事実上、1 つの命令で多数の命令になります)。たとえば、前の命令をキャンセルする命令は、まず前のトランザクションをキャンセルし、次に特定の値を再計算する必要があることを意味します。また、単一の命令が過負荷になる可能性があります。これは、以前の命令をキャンセルしたり、解決策を投票したりするためです。

ドメインサービスを使用して新しい命令を処理するように勧められました。

BondService
{
    public void Apply(Instruction newInstruction)
    {
        var bond = _bondRepository.GetByReference(newInstruction);
        bond
            .RecalculateNominalValue(newInstruction)
            .CalculateInterest(newInstruction)
            .CancelInstruction(newInstruction)
            .Approve(newInstruction);
    }
}

この構造で見られる問題は、メソッドが関連していなくても、命令ごとにすべてのメソッドが呼び出されることです。if ステートメントを使用することもできますが、コードが乱雑に見えます。

今、私の質問は、

これはモデル化するための最良の方法ですか？
また、計算については、債券の種類によって計算が異なります。だから私はポリモーフィズムを実装したい。ファクトリを使用して正しい実装をインスタンス化する必要があると言われました。これは最善のアプローチですか？

BondType 1,3,5 の場合、計算 A を使用し、bondType 2,7 の場合...計算 B を使用する必要があります。異なる計算タイプをインスタンス化するにはどうすればよいですか??? NB、私はポリモーフィズムに精通していますが、正しい実装をインスタンス化する方法の確かな例を見つけることができませんでした。ここまで読んでくれてthnx…

domain-driven-design - オブジェクトのインスタンス化 - ポリモーフィズム

1 に答える 1

Related

Reference