model Ledger

บทที่แล้วเราสรุปหลักการไว้สองข้อ — เงินทุกการเคลื่อนไหวต้องบันทึกเป็นสองขาที่สมดุล และ Ledger คือแหล่งความจริงเดียวที่เก็บทุกรายการต่อท้ายกันไปเรื่อยๆ ห้ามแก้ ห้ามลบ ส่วนยอดเงินคงเหลือไม่ใช่ตัวเลขที่เก็บไว้ตรงๆ แต่เป็นสิ่งที่คำนวณจากประวัติ บทนี้เราจะแปลหลักการเหล่านั้นให้กลายเป็นรูปทรง C# จริง — ปั้น ledger ให้เป็น aggregate ที่ “รักษากฎสมดุลไว้ในตัวเอง” คือถ้ารายการไหนไม่สมดุล มันต้องสร้างไม่ขึ้นตั้งแต่แรก ไม่ใช่รอไปตรวจเจอทีหลังตอนเงินหายไปแล้ว

model ของเรามีตัวละครที่ต่อกันเป็นชั้นๆ: Account บอกว่าเงินอยู่ตรงไหน, LedgerEntry คือบรรทัดเดียวที่บันทึกว่าเดบิตหรือเครดิตบัญชีไหนเท่าไร, Journal Entry คือชุดของ LedgerEntry ที่ต้องสมดุลกันทั้งก้อน และ ledger คือ aggregate ที่ถือ log ทั้งหมดไว้แล้วเปิดให้ “post” journal entry ใหม่ต่อท้ายได้อย่างเดียว เราจะไล่สร้างจากชิ้นเล็กที่สุดไปหาก้อนใหญ่

📦 code ตัวอย่าง (กำลังจัดทำ)

code เต็มของคอร์สนี้อยู่ที่ repo kaen-food-ordering (กำลังจัดทำ) — บทนี้เริ่มปั้นโครง domain ของ money context จริง รูปทรง C# ของ Ledger, Account, LedgerEntry และ JournalEntry ที่เห็นในบทเป็นตัวอย่างประกอบให้เห็นภาพ ส่วน value object Money ยกมาจากคอร์ส DDD-in-Code ทั้งดุ้น (path เดิม FoodOrdering.Domain/Orders/Money.cs)

Ledger — aggregate ที่รักษากฎสมดุลไว้ในตัวเอง

aggregate ในภาษา DDD คือกลุ่มของ object ที่มี “ผู้รักษากฎ” คนเดียวคอยดูแลว่าสถานะข้างในถูกกติกาเสมอ สำหรับ money context ของเรา ผู้รักษากฎคนนั้นคือ ledger — มันถือรายการทั้งหมดไว้เป็น Append-only Log คือต่อท้ายได้อย่างเดียว ไม่มี method ไหนเปิดให้ UPDATE หรือ DELETE รายการเก่าเลย และมันยอมรับ journal entry ใหม่ก็ต่อเมื่อรายการนั้นสมดุลแล้วเท่านั้น

จุดนี้สำคัญ: กฎ “เงินไม่มีวันหาย” ถูกบังคับไว้ที่ขอบของ aggregate เดียว ไม่รั่วออกไปให้ code ส่วนอื่นเผลอทำพัง code ที่เรียกใช้ ledger ทำได้อย่างเดียวคือยื่น journal entry ที่สมดุลแล้วเข้าไป post จะแอบไปขยับยอดบัญชีตรงๆ ไม่ได้ เดี๋ยวเราจะเห็น code ของ ledger ตอนพูดเรื่อง Post แต่ก่อนอื่นมาปั้นชิ้นส่วนที่มันถือไว้ให้ครบก่อน

Account — บอกว่าเงินอยู่ตรงไหน

Account คือหน่วยที่ตอบว่า “เงินก้อนนี้อยู่ตรงไหนในระบบ” money context ของเรามีบัญชีอยู่หกประเภทตายตัว ทั้งคอร์สจะวนอยู่กับกลุ่มนี้ ไม่มีการสร้างประเภทใหม่พร่ำเพรื่อ เราจึงล็อกมันไว้ใน enum:

// AccountId — value object ห่อ Guid ไว้ ไม่ให้ปนกับ id ชนิดอื่นใน domain
public sealed record AccountId(Guid Value);

// หกประเภทบัญชีของ money context นี้
public enum AccountType
{
    CustomerWallet,     // wallet ลูกค้า — platform ติดค้างลูกค้า (หนี้สิน)
    RestaurantPayable,  // เจ้าหนี้ร้านอาหาร — เงินที่ติดค้างร้าน (หนี้สิน)
    RiderPayable,       // เจ้าหนี้ไรเดอร์ — เงินที่ติดค้างไรเดอร์ (หนี้สิน)
    PlatformRevenue,    // รายได้ platform — ค่าคอมมิชชันที่หักเก็บเป็นของตัวเอง
    GatewayClearing,    // บัญชีพักตอนรับเงินเข้าจาก gateway (สินทรัพย์)
    Escrow,             // บัญชีพักเงินค่าอาหารระหว่างออเดอร์กำลังส่ง (หนี้สิน)
}

สังเกตว่าบัญชีแต่ละประเภทมี “ด้านปกติ” ที่ทำให้ยอดเพิ่มต่างกัน ตามที่บทที่ 1 ปูไว้: บัญชีฝั่งหนี้สินและรายได้ (wallet, เจ้าหนี้ร้าน, เจ้าหนี้ไรเดอร์, รายได้ platform, escrow) เครดิตทำให้ยอดเพิ่ม ส่วนบัญชีฝั่งสินทรัพย์ (GatewayClearing) เดบิตทำให้ยอดเพิ่ม เราจะเอาความรู้ข้อนี้ไปใช้ตอนคำนวณยอดคงเหลือ

สองในหกประเภทเป็นบัญชีพักเงินชั่วคราว — Clearing Account คือ GatewayClearing พักเงินตอนเพิ่งรับเข้าจาก gateway ก่อนกระจายต่อ และ Escrow Account คือ Escrow กันเงินค่าอาหารไว้ระหว่างออเดอร์กำลังส่ง ทั้งสองจะได้บทเต็มของตัวเองข้างหน้า บทนี้แค่จองที่ไว้ใน model ก่อน

LedgerEntry — บรรทัดเดียวที่เขียนแล้วห้ามแก้

ก่อนจะไปถึง journal entry ขอทวน Money จากบทที่ 1 สั้นๆ ก่อน เพราะทุก LedgerEntry อ้างถึงมัน — เงินในระบบนี้ไม่ใช่ decimal เปล่าๆ แต่เป็น value object ที่ห่อจำนวนกับสกุลเงินไว้ด้วยกันและบวกกันได้:

// ทวน Money จากบทที่ 1 (ยกมาจากคอร์ส DDD-in-Code ทั้งดุ้น)
// FoodOrdering.Domain/Orders/Money.cs — แสดงเฉพาะส่วนที่บทนี้ใช้
public sealed record Money(decimal Amount, string Currency)
{
    public Money
    {
        if (Amount < 0)
            throw new ArgumentException("จำนวนเงินต้องไม่ติดลบ", nameof(Amount));
        if (Currency != "THB")
            throw new ArgumentException("ตอนนี้รองรับเฉพาะสกุลเงิน THB", nameof(Currency));
    }

    public static Money Thb(decimal amount) => new(amount, "THB");

    public static Money operator +(Money a, Money b)
    {
        if (a.Currency != b.Currency)
            throw new InvalidOperationException("บวกเงินต่างสกุลกันไม่ได้");
        return new Money(a.Amount + b.Amount, a.Currency);
    }
}

ทีนี้ LedgerEntry คือบรรทัดเดียวใน ledger ที่บอกว่า “รายการนี้เดบิตหรือเครดิตบัญชีไหน จำนวนเท่าไร และสังกัด journal entry ใบไหน” หัวใจของมันคือ Immutability — เขียนลงไปแล้วต้องแก้ไม่ได้ตลอดกาล เราจึงใช้ record ที่รับค่าครบตอนสร้างแล้วไม่มี setter ให้ขยับ:

// JournalEntryId — value object ห่อ Guid ของ journal entry ที่รายการนี้สังกัด
public sealed record JournalEntryId(Guid Value);

public enum Direction { Debit, Credit }

// LedgerEntry — บรรทัดเดียวใน ledger, immutable: เขียนแล้วห้ามแก้/ลบ
public sealed record LedgerEntry(
    AccountId AccountId,
    Direction Direction,
    Money Amount,
    JournalEntryId JournalEntryId);

Direction มีแค่ Debit กับ Credit — ไม่มีค่าที่สาม ไม่มีเครื่องหมายบวกลบให้เผลอใส่ผิด ส่วน JournalEntryId ที่ผูกติดไว้ทำให้ทุกบรรทัดรู้ว่าตัวเองเกิดจากธุรกรรมใบไหน เวลาไล่ audit ย้อนหลังจึงจับกลุ่มกลับมาเป็นรายการเดียวได้เสมอ

Journal Entry — ชุดรายการที่ต้องสมดุล ★

journal entry หนึ่งใบคือชุดของ LedgerEntry ที่ต้องสมดุลกันทั้งก้อน — นี่คือที่ที่ invariant ★ หัวใจของทั้งคอร์สอยู่: ผลรวมของขาเดบิตต้องเท่ากับผลรวมของขาเครดิตพอดี ถ้าไม่เท่า แปลว่ารายการนั้นทำเงินหายหรือเสกเงินขึ้นมาเอง เราจึงบังคับกฎนี้ไว้ใน constructor: สร้าง JournalEntry ที่ไม่สมดุลไม่ได้เลย object แบบนั้นเกิดขึ้นในหน่วยความจำไม่ได้ตั้งแต่แรก

public sealed class JournalEntry
{
    public JournalEntryId Id { get; }
    public string IdempotencyKey { get; }   // กัน post ซ้ำ — ทวนแนวคิดจากคอร์ส Bounded Contexts
    public string Reason { get; }           // เหตุผลของรายการ ไว้ตรวจย้อนหลังว่าเกิดอะไร
    public IReadOnlyList<LedgerEntry> Entries { get; }

    public JournalEntry(
        JournalEntryId id,
        string idempotencyKey,
        string reason,
        IReadOnlyList<LedgerEntry> entries)
    {
        if (entries.Count < 2)
            throw new ArgumentException("journal entry ต้องมีอย่างน้อยสองขา", nameof(entries));

        Money debits  = entries.Where(e => e.Direction == Direction.Debit)
                               .Aggregate(Money.Thb(0), (sum, e) => sum + e.Amount);
        Money credits = entries.Where(e => e.Direction == Direction.Credit)
                               .Aggregate(Money.Thb(0), (sum, e) => sum + e.Amount);

        // ★ invariant หัวใจของทั้งคอร์ส: เดบิตรวมต้องเท่ากับเครดิตรวมพอดี
        if (debits != credits)
            throw new InvalidOperationException(
                $"journal entry ไม่สมดุล: เดบิตรวม {debits.Amount} ≠ เครดิตรวม {credits.Amount}");

        Id = id;
        IdempotencyKey = idempotencyKey;
        Reason = reason;
        Entries = entries;
    }
}

เพราะ Money เป็น value object ที่เทียบเท่ากันด้วยค่า บรรทัด debits != credits จึงเทียบยอดสองก้อนได้ตรงๆ ไม่ต้องกังวลเรื่องหน่วยเงินหรือการปัดเศษ และเพราะ Money.Thb(0) เป็น seed ของการพับ ทุกขาจึงถูกบวกเข้าด้วย operator + ตัวเดิม กฎสมดุลจึงกลายเป็นเงื่อนไขเดียวสั้นๆ ที่ผ่านหรือไม่ผ่านก็รู้ทันทีตอนสร้าง object

Post — ต่อท้าย log อย่าง idempotent

มาถึงตัว aggregate เอง Ledger ถือ log ไว้เป็น List ที่มีทางเข้าออกอย่างเดียวคือ “ต่อท้าย” และเปิด method Post ให้รับ journal entry ที่สมดุลแล้วเข้ามาบันทึก:

public sealed class Ledger
{
    private readonly List<LedgerEntry> _log = new();       // append-only: ต่อท้ายอย่างเดียว
    private readonly HashSet<string> _postedKeys = new();  // จำ idempotency key ที่เคย post

    public IReadOnlyList<LedgerEntry> Entries => _log;

    // Post เป็น idempotent: post journal entry ที่มี key เดิมซ้ำ ไม่เพิ่มรายการซ้ำ
    public void Post(JournalEntry entry)
    {
        if (!_postedKeys.Add(entry.IdempotencyKey))
            return;                          // เคย post key นี้แล้ว — ข้าม ไม่ต่อรายการซ้ำ

        _log.AddRange(entry.Entries);        // ต่อท้าย log เท่านั้น ไม่เคยแก้/ลบของเก่า
    }
}

ตรงนี้เรายืมของจากคอร์ส Bounded Contexts มาโดยไม่รื้อสอนใหม่ ในทางปฏิบัติ ledger ไม่ได้ post รายการเอง แต่ทำงานตอบสนอง Integration Event ที่ Ordering context ส่งข้ามมา เช่น OrderConfirmed (ยืนยันออเดอร์แล้ว) กับ OrderDelivered (ส่งถึงมือลูกค้าแล้ว) — สัญญาของ event พวกนี้มีแต่ ID กับค่า primitive ตามที่คอร์สนั้นวางไว้ ส่วนตัว payment gateway อย่าง PromptPay อยู่หลัง ACL (IPaymentGateway) เป็นแค่ภาพประกอบในคอร์สนี้ ไม่ใช่การต่อจริง

เพราะ event เดิมอาจถูกส่งซ้ำเวลาเครือข่ายมีปัญหา เราจึงต้องเป็น Idempotent Consumer คือรับข้อความเดิมซ้ำกี่ครั้งก็ให้ผลเหมือนเดิม กลไกที่ใช้คือ Idempotency Key ที่ติดมากับ journal entry — Post เช็คก่อนว่าเคยเห็น key นี้ไหม ถ้าเคยก็ข้ามไปเงียบๆ ไม่บันทึกรายการซ้ำ ลูกค้าจึงไม่โดนหักเงินสองรอบเพราะ retry

แล้วถ้า post ผิดล่ะ ลบทิ้งได้ไหม — ไม่ได้เด็ดขาด การแก้หรือลบทำลายประวัติที่ audit ได้ วิธีที่ถูกต้องคือเขียน Reversing Entry — journal entry ใหม่ที่สลับด้านเดบิต/เครดิตของรายการเดิมมาหักล้าง ประวัติเดิมยังอยู่ครบ เห็นได้ว่าเกิดอะไรขึ้นและถูกแก้ยังไง เรื่องนี้จะมีบทเต็มตอนพูดถึง refund ข้างหน้า

ยอดคงเหลือคือผลของการพับ ไม่ใช่ column

คำถามสุดท้าย: แล้ว “ยอดเงินในบัญชี” มาจากไหน คำตอบคือ Balance as a Fold — ยอดคงเหลือไม่ใช่ column ที่เก็บไว้ แต่เป็นผลของการ “พับ” (fold) ไล่บวก-ลบทุก LedgerEntry ที่กระทบบัญชีนั้น โดยดูจากด้านปกติของบัญชีว่าเดบิตหรือเครดิตคือด้านที่ทำให้ยอดเพิ่ม:

public sealed class Account
{
    public AccountId Id { get; }
    public AccountType Type { get; }

    public Account(AccountId id, AccountType type) => (Id, Type) = (id, type);

    // ★ ยอดคงเหลือไม่ใช่ column ที่เก็บไว้ — พับ (fold) ทุก LedgerEntry ที่กระทบบัญชีนี้
    public Money Balance(IEnumerable<LedgerEntry> log)
    {
        decimal running = log
            .Where(e => e.AccountId == Id)
            .Aggregate(0m, (acc, e) =>
                e.Direction == NormalSide ? acc + e.Amount.Amount
                                          : acc - e.Amount.Amount);
        return Money.Thb(running);
    }

    // "ด้านปกติ" ที่ทำให้ยอดเพิ่ม ขึ้นกับประเภทบัญชี (ทวนจากบทที่ 1)
    private Direction NormalSide => Type switch
    {
        AccountType.GatewayClearing => Direction.Debit,  // สินทรัพย์: เดบิตทำให้ยอดเพิ่ม
        _                           => Direction.Credit, // wallet/payable/revenue/escrow (หนี้สิน/รายได้): เครดิตทำให้ยอดเพิ่ม
    };
}

Aggregate(0m, ...) คือการพับตรงๆ: เริ่มจากศูนย์ แล้วไล่แต่ละรายการ ถ้าตรงกับด้านปกติของบัญชีก็บวก ไม่งั้นก็ลบ ได้เท่าไรค่อยห่อกลับเป็น Money ตอนจบ ผลพลอยได้คือถ้าบัญชีที่ควรมียอดไม่ติดลบดันคำนวณได้ติดลบ Money.Thb จะโยน exception ทันที — เป็น fail-fast ที่คอยจับ bug ในระบบบันทึกให้เราฟรีๆ

ลองเดินครบวงจรหนึ่งรอบ ตอนลูกค้าเติมเงินเข้า wallet 200 บาทผ่าน PromptPay:

var ledger = new Ledger();
var gatewayClearingId = new AccountId(Guid.NewGuid());
var customerWalletId  = new AccountId(Guid.NewGuid());
var customerWallet    = new Account(customerWalletId, AccountType.CustomerWallet);

var jeId = new JournalEntryId(Guid.NewGuid());
var topUp = new JournalEntry(
    id: jeId,
    idempotencyKey: "promptpay:txn-4821",
    reason: "ลูกค้าเติมเงินเข้า wallet 200 บาท",
    entries: new[]
    {
        new LedgerEntry(gatewayClearingId, Direction.Debit,  Money.Thb(200), jeId),
        new LedgerEntry(customerWalletId,  Direction.Credit, Money.Thb(200), jeId),
    });

ledger.Post(topUp);                                          // ต่อท้าย log; post key เดิมซ้ำก็ไม่เพิ่มรายการ
Money walletBalance = customerWallet.Balance(ledger.Entries); // = 200 บาท (พับจากรายการ ไม่ใช่ column)

flowchart TB
  JE["JournalEntry — สมดุล ★<br/>เดบิตรวม = เครดิตรวม<br/>+ idempotency key + reason"]
  JE --> D["LedgerEntry · เดบิต<br/>GatewayClearing +200"]
  JE --> C["LedgerEntry · เครดิต<br/>CustomerWallet +200"]
  D -->|Post ต่อท้าย log| A1["บัญชี GatewayClearing"]
  C -->|Post ต่อท้าย log| A2["บัญชี CustomerWallet"]
  A2 --> F["ยอดคงเหลือ = พับ fold ทุก LedgerEntry ของบัญชี<br/>ไม่ใช่ column ที่เก็บไว้"]
  classDef je fill:#1e3a8a,stroke:#1e40af,color:#f8fafc;
  classDef dr fill:#16a34a,stroke:#065f46,color:#f8fafc;
  classDef cr fill:#dc2626,stroke:#7f1d1d,color:#f8fafc;
  classDef acc fill:#0f766e,stroke:#134e4a,color:#f8fafc;
  classDef fold fill:#f59e0b,stroke:#92400e,color:#1c1917;
  class JE je;
  class D dr;
  class C cr;
  class A1,A2 acc;
  class F fold;

คำบรรยายภาพ: journal entry หนึ่งใบ (น้ำเงิน) แตกเป็น LedgerEntry สองขาที่สมดุล — ขาเดบิต (เขียว) เข้าบัญชี GatewayClearing และขาเครดิต (แดง) เข้าบัญชี CustomerWallet จำนวนเท่ากันเป๊ะ จุด ★ คือ invariant ที่ constructor รักษาไว้: ถ้าเดบิตรวมไม่เท่าเครดิตรวม journal entry นี้สร้างไม่ขึ้น เมื่อผ่านแล้ว Post จะต่อทั้งสองบรรทัดท้าย log (บัญชีสีเขียวเข้ม) แบบ append-only ส่วนยอดคงเหลือ (ส้ม) ไม่ได้เก็บไว้ที่ไหน แต่คำนวณสดๆ ด้วยการพับทุก LedgerEntry ของบัญชีนั้นทุกครั้งที่ถาม

สิ่งที่จะทำต่อ

ตอนนี้เรามีโครงของ money context ครบทุกชิ้น — Ledger ที่รักษากฎสมดุล, Account หกประเภท, LedgerEntry ที่ immutable และ JournalEntry ที่บังคับ invariant ในตัวเอง บทต่อไปเราจะเอาโครงนี้ไปรับงานจริงชิ้นแรก: เติมเงินเข้า wallet ด้วย PromptPay (บทที่ 3) — รับสัญญาณจาก gateway ที่ขอบ แล้วแปลงเป็น journal entry เข้ามาใน ledger พร้อมใช้ idempotency key กันหักเงินซ้ำเวลา retry จากนั้นจึงไล่เรื่องต่อไปที่ escrow, settlement, payout, refund และปิดท้ายด้วย reconciliation

ทุกบทจะกลับมา post ลง ledger เดียวกันนี้เสมอ — ไม่มี column ยอดเงินให้เขียนทับ มีแต่รายการที่ต่อท้ายไปเรื่อยๆ และยอดคงเหลือที่พับออกมาจากประวัติได้ทุกเมื่อ

🔗 อ้างอิงเพิ่มเติมใน DevIQ

เจาะลึกแนวคิดในบทนี้ต่อได้ที่คลังอ้างอิง DevIQ:

Aggregate — ทำไม Ledger ถึงเป็น aggregate ที่รักษา invariant สมดุลไว้ที่ขอบเดียว code ข้างนอกขยับยอดบัญชีตรงๆ ไม่ได้
Value Object — ทำไม AccountId, JournalEntryId และ Money ถึงห่อ primitive ไว้ แทนที่จะส่ง Guid/decimal เปล่าๆ ไปทั้งระบบ
Make Illegal States Unrepresentable — ทำไม journal entry ที่ไม่สมดุลถึงควร “สร้างไม่ขึ้น” ตั้งแต่ constructor ไม่ใช่ปล่อยให้มีอยู่แล้วค่อยไล่ตรวจ

เช็กความเข้าใจ — บทที่ 2

ข้อ 1 / 3

invariant หลักที่ทำให้ JournalEntry ใน model ledger นี้ถูกต้องคืออะไร?

model Ledger

Ledger — aggregate ที่​รักษา​กฎ​สมดุล​ไว้​ใน​ตัวเอง

Account — บอกว่า​เงิน​อยู่​ตรง​ไหน

LedgerEntry — บรรทัด​เดียว​ที่​เขียน​แล้ว​ห้าม​แก้

Journal Entry — ชุด​รายการ​ที่​ต้อง​สมดุล ★

Post — ต่อ​ท้าย log อย่าง idempotent

ยอด​คง​เหลือ​คือ​ผล​ของ​การ​พับ ไม่ใช่ column

สิ่ง​ที่​จะ​ทำ​ต่อ