web-dev-qa-db-ja.com

さまざまな種類の口座取引

ユーザーが財務タイプのさまざまなタイプの「アカウント」を持っているシステムに取り組んでいます。私はうまくいくデザインを思いつくのに苦労しています。

バックグラウンド

ユーザーには、「タブ」アカウントと「負債」アカウントの2種類のアカウントがあります。

債務

ここでは、「本社」がユーザーの代金を支払います。イベント、ディナーなどのようなものです。ある時点で、ユーザーはアカウントにお金を追加して残高をゼロに戻します。これは単なるトランザクションであるため、これをモデル化することに問題はありません。

タブ

このアカウントは、ユーザーが行った注文に関連するトランザクションを保持します。たとえば、ユーザーがバーから2つのドリンクを注文します。このコストも、トランザクションを生成した注文を参照するトランザクションとしてモデル化する必要があると思います。

ここでは、口座にも残高があります。注文に固有

今、私はそれをこのようにモデル化しました。

public abstract class Account
{
    public Guid Id { get; set; }

    public decimal Balance { get; set; }

    public DateTime LastUpdated { get; set; }


}

public class DebtAccount: Account
{

    public ICollection<DebtTransaction> Transactions { get; set; }
}

public class TabAccount: Account
{
    public ICollection<TabTransaction> Transactions { get; set; }
}

public abstract class Transaction
{
    public Guid Id { get; set; }

    public decimal Amount { get; set; }

    public DateTime Date { get; set; }

    public string Description { get; set; }
}

public class TabTransaction : Transaction
{
    public Orderline Consumption { get; set; }
}

public class DebtTransaction : Transaction
{

}



 public class User {

public DebtAccount DebtAccount {get;set;}
public TabAccount TabAccount {get;set;}

}

私はそれを見て、何かが正しくないと感じますが、もっと良い解決策を思いつくことはできません。

それをデータベース設計に変換する方法についても苦労しています。

追加情報：アプリケーションはC＃、. NET、Entity Frameworkで作成しています。

小さいか大きいかすべてのアドバイスは大歓迎です。

c#domain-driven-designdatabase-designentity-frameworkdomain-model
2
Thomas de Wulf

あなたは別々にすべきであるさまざまなアイデアを結び付けています。

トランザクションは、相手のアカウントのタイプに関係なく同じであるため、異なるタイプであってはなりません。店で何かを買うことを考えてください。現金またはクレジットカード（基本的にはタブ）を持っているかどうかに応じて、プロセスに異なるアプローチをとることはありません。トランザクションは、指定された金額が何らかの方法で満たされていることのみを考慮します。

TabAccountとDebtAccountも同じものです。これは、トランザクションと実行残高を保持するためのコンテナです。あなたはそれらの両方を取り除き、ただアカウントを保持するべきです。メモリ内に2つのアカウント（TabAcountとDebtAccount）をインスタンス化しますが、どちらもクラスタイプはAccountです。

会計の核となる原則の1つは複式簿記です。すべてのトランザクションには、デビットアカウントとクレジットアカウントが必要です。トランザクションにDebitAccountプロパティとCreditAccountプロパティを配置する必要があります。 Debt and Tabアカウントのみで、トランザクションの反対側に何もありません。そのためにはInventoryValueOnHandアカウントが必要なので、他のアカウントが増加するとInventoryValueOnHandが減少します。

これにより、ユーザー、アカウント、トランザクションの3つのクラスだけが残ります。 DBでは、ユーザーはアカウントと1対多の関係、アカウントはトランザクションと1対多の関係、トランザクションはアカウントと2対1の関係（デビットおよびクレジットアカウント）を持っています。

3
Brad Irby

behaviorがないモデルはありません。これらのオブジェクトがどの機能を提供する必要があるかを知らなければ、詳細について説明する意味がありません。

これらのオブジェクトが提供する必要のある関連機能をすべて収集し、それらの機能がモデルを駆動できるようにします。たとえば、TabとDebtアカウントに別々の機能がある場合、それらは別々のオブジェクトであり、そうでない場合はそうではありません！

本質的には、モデリングを別の方法で行う必要があります。 「データ」と「関係」を忘れてください。最初に関数をモデル化します。それらはあなたにオブジェクトを与えます。その後、誰がどのデータを保持するかを決定できます。

1
Robert Bräutigam