會計分錄
一筆金額的分配
2005 年 1 月 22 日
這是 進一步的企業應用程式架構開發 寫作的一部分，我在 2000 年代中期進行。遺憾的是，自那以後，太多其他事情吸引了我的注意力，所以我沒有時間進一步處理它們，我也看不到未來可預見的太多時間。因此，這份資料很大程度上是草稿形式，而且在我能找到時間再次處理它之前，我不會進行任何更正或更新。
星期二，我從我的支票帳戶中提領 100 美元。這將是一筆金額為 100 美元、日期為星期二、描述為我的支票帳戶的會計分錄。
一位承包商在星期六花費 300 美元購買我家工程的電器用品。這將是一筆日期為星期六、金額為 300 美元、描述為我家工程的專案和電器用品成本類別的會計分錄。
三桶 Old Peculier 送到 Square and Compass。這將是一筆金額為三桶（數量）的會計分錄，其描述為 Old Peculier 和 Square and Compass。
會計圍繞著金錢，基本上是關於金錢的分類：它的來源、用途，甚至應該如何使用它。從文藝復興時期開始，記錄這種方式就是分類帳中的分錄，在當時是一個實體書。此類分錄會記錄金錢的進出。它們也會記錄實際上根本不會造成任何金錢移交的事項，例如轉帳。
運作方式
分類帳的頁面對應於特定的金錢分類，現在它們會稱為帳戶，因此 帳戶 通常與 會計分錄 搭配。事實上，在分析模式中，我將它們放在同一個模式中。但並非總是如此。有些人認為沒有帳戶的分錄，有些人認為所有分錄都只是帳戶的一部分。我將在 帳戶 中討論它們緊密結合的情況，在那之前，只要將帳戶視為分錄的一個可能的描述符即可。
將分錄視為影響網域的有趣事物並不牽強，因此 網域事件 很可能適用於 會計分錄。有時候我會看到這樣，有時候我會看到兩者分開。重要的是，當您使用 會計分錄 時，您需要提出 網域事件 所提出的問題。（分錄應該是不可變的嗎？它們應該有什麼日期？）
通常會針對何時可以變更分錄有具體規則。當分錄處於開放狀態時，可能會允許變更分錄，但當它們關閉或登錄時，不允許變更分錄。
在特定模型中，通常會將描述符建模為獨立類別，與條目有獨立的關係。因此，如果我們執行工作成本計算，我們可能希望用專案和成本類型標記每個條目。專案和成本類型是條目的描述符。在我們的模型中，我們會將這些顯示為獨立的關係，如 圖 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();
}