Design the object model and public APIs for an expense-sharing core: the classes that let people in a group record who paid for what, split each cost among participants, track what everyone owes, and settle up. This is the domain kernel a mobile app or an API layer would drive, not the UI or the storage engine.

Operating context. People organize into groups (a trip, a flat, a dinner). Any member records an expense: an amount, who paid it (one or several payers), and how it splits across participants. A split can be equal (divide evenly), exact (named amounts per person that must sum to the total), or by percentage (shares that must sum to 100). From the stream of expenses the system derives each person's net balance and the pairwise "who owes whom". Members settle debts with payments, and the system can propose a minimized set of transfers that clears all balances with the fewest transactions. The recorded ledger is append-only: an expense is never edited in place; a mistake is corrected by a reversing or superseding entry so history stays auditable. Assume a single in-process instance and integer minor currency units (never floats).

Out of scope. Persistence and database schema, authentication and membership permissions, multi-currency conversion and FX rates, notifications and activity feeds, and the REST/GraphQL surface (design the in-process object graph, not the transport layer).

What to produce. The class hierarchy (User, Group, Expense, the Split types, Payment/Settlement, and the balance/ledger services), the public API each class exposes, and the key state transitions. Be explicit about: how the three split strategies plug in behind one interface so a fourth (e.g. by shares) is added without editing existing code; how validation rejects a split whose parts do not reconcile to the total to the minor unit; how balances are derived from the immutable ledger rather than mutated counters; and how debt simplification reduces a tangle of pairwise debts to a minimal transfer set.