会計仕訳

金額の割り当て

2005年1月22日

これは、2000年代半ばに執筆していた「Further Enterprise Application Architecture development（エンタープライズアプリケーションアーキテクチャ開発のさらなる発展）」の一部です。残念ながら、それ以来、他の多くのことが私の注意を引いてしまい、それらをさらに進める時間がありませんでしたし、近い将来にも時間が見込めそうにありません。そのため、この資料は非常に草稿の状態であり、再び作業に取り組む時間ができるまで、修正や更新は行いません。

私は火曜日に当座預金口座から100ドルを引き出しました。これは、金額が100ドル、日付が火曜日、記述子が当座預金口座である会計仕訳となります。

請負業者が土曜日に私の家の電気工事のために300ドルを費やしました。これは、日付が土曜日、金額が300ドル、記述子が私の家の工事プロジェクトと電気工事費のカテゴリーである会計仕訳となります。

オールド・ペキュリアの樽が3つ、スクエア・アンド・コンパスに納品されました。これは、金額が3樽（数量）、記述子がオールド・ペキュリアとスクエア・アンド・コンパスである会計仕訳となります。

会計は、お金を中心に展開し、本質的にはお金の分類、つまり、お金の出所、用途、さらには、本来の用途についてです。ルネサンス時代から、これを記録する方法は元帳への記入であり、当時は物理的な帳簿でした。このような記入には、入金と出金が記録されます。また、実際には金銭の受け渡しを伴わないもの、例えば振替なども記録されます。

仕組み

元帳のページは、特定の金銭の分類に対応しており、今日では勘定科目と呼ばれています。そのため、「勘定科目」はしばしば「会計仕訳」と関連付けられます。実際、私は「アナリシスパターン」の中で、これらを同じパターンに分類しました。しかし、常にそうであるとは限りません。勘定科目を持たない仕訳もあれば、すべての仕訳を単に勘定科目の一部と見なす場合もあります。ここでは、それらが密接に結びついている場合について、「勘定科目」で説明します。それまでは、勘定科目を仕訳の記述子の1つと考えてください。

仕訳をドメインに影響を与える興味深いものと考えることは難しくありません。そのため、「ドメインイベント」が「会計仕訳」に適用される可能性は十分にあります。私はこれを目にすることもあれば、両者が分離されているのを見ることもあります。「会計仕訳」を使用する際には、「ドメインイベント」で提起された質問をする必要があります。（仕訳は不変であるべきか？どのような日付を持つべきか？）

仕訳を変更できる時期については、特定のルールがあることがよくあります。仕訳が未確定の状態であれば変更が許可される場合がありますが、確定または記帳済みの場合は変更できません。

特定のモデルでは、通常、記述子を個別のクラスとしてモデル化し、仕訳との間に個別の関係を持たせます。そのため、例えば、ジョブ原価計算を行う場合、各仕訳にプロジェクトと原価計算タイプをマークしたい場合があります。プロジェクトと原価計算タイプは、仕訳の記述子です。私たちのモデルでは、図1のように、これらを個別の関係として示します。

図1：記述子としてのプロジェクトと原価計算タイプ

イベントソーシングの使用

イベントソーシングは、「会計仕訳」と特に相性が良いです。イベントからのすべての会計変更を、新しく作成された「会計仕訳」のセットとして表現できるからです。さらに、「会計仕訳」をそれを引き起こした「ドメインイベント」にリンクさせると、「ドメインイベント」とその結果との間に迅速にリンクを形成できます。これは、強力な監査証跡を作成するだけでなく、「遡及イベント」に必要な処理を容易に実行できるようにします。

図2：「ドメインイベント」を、それによって作成されたすべての「会計仕訳」に接続すると、監査と後続の処理に役立ちます。

いつ使うか

何らかの量的値の変化を記録する必要がある場合は常に、仕訳を使用する必要があります。最も明白なケースは、金銭的価値のすべての変化を記録する場合です。実際、これは、ほとんどのビジネスにとって金銭が中心的な存在であり、このレベルの追跡が必要となるため、一般的なケースです。

このパターンは、仕訳が金銭金額に対して行われる最も一般的なケースを示唆しています。ただし、何かの数量、あるいはソースコード管理システムの差分など、差分を含むものを分類したい場合はいつでも、このパターンを使用できます。これは、何にでも適用できる過度に汎用的なモデルを使用しているように聞こえます。このような過度に汎用的なモデルは危険な人魚であり、その美しさは多くのアナリストを、必ずしも致命的ではないにしても、いらいらさせる溺死のバリエーションへと誘い込みます。しかし、この抽象化の価値は、「会計仕訳」に基づいて構築された他のパターンが意味をなすかどうかにあるのです。そのため、可能性として心に留めておいてください。ただし、まずは泳げることを確認してください。

例：単純な例（Java）

単純な状態では、「会計仕訳」はほとんどの場合、単純なデータホルダーです。

interface Entry {
   Entry newEntry (CostType costType, Project project, Money amount, Date date);
   CostType getCostType();
   Project getProject();
   Money getAmount();
   Date getBookingDate();

記述子は、通常、パターンの特定のアプリケーションでは明示的な型として表示されます。

仕訳は、常に不変である場合もあれば、記帳されるまで可変である場合もあります。これは、次のような設定メソッドにつながります。

    void setCostType (CostType arg) {
       if (isOpen())
        costType = arg
       else
        throw new ImmutableEntryException();
    }