Здравствуйте, SV., Вы писали:

SV.>Так вот. Свой счет я посадил бы поверх таблицы проводок, и он бы хранил внутренний уникальный идентификатор плюс банковскую атрибутику. Получение состояния на любой момент времени, оборотов за период (а также входящее и исходящее сальдо периода) было бы реализовано в нем в виде методов. Там же — валютный пересчет на основе входящей ссылки на объект, представляющий Форекс (или, по-простому, конфиг текущей сессии). И это как раз и есть модель реального счета.
Совершенно непонятно, зачем всё это запихивать в счёт.
SV.>С одной стороны она соответствует модели в голове у бухгалтера, поскольку основывается на проводках.
Не соответствует.
SV.>С другой стороны, ее можно отдать, допустим, программисту гуёв, и он найдет в ней и .CalcCurrentBalance(), и что его душе угодно. Не проблема хранить пачку счетов (вектор, например), поскольку реальные инкапсулируемые данные в памяти малы.
SV.>Вся эта штука называется объектная модель.
Вся эта штука называется "ошибка архитектуры".
У неё нет никаких преимуществ. То есть совсем никаких. У счетов нет полиморфизма поведения, поэтому нечего и абстрагировать. Точнее, у счёта вообще нет поведения. Вы зачем-то хотите помещать .CalcCurrentBalance() внутрь объекта Account — а зачем?
Смотрите, в чём затык: для вывода баланса на экран придётся построить новый счёт и попросить данные у него:

BalanceLabel.Text = (new Account("03")).CalcCurrentBalance().ToString();

А что такое "Current"? Наверное, есть операция CalcBalanceForDate(Date targetDate), и есть важный инвариант CalcCurrentBalance() == CalcBalanceForDate(new Date()). Этот инвариант верен для всех счетов; то есть, с точки зрения правильного дизайна надо его выносить наружу. Ок, CalcCurrentBalance мы отобрали.
Теперь, код, который я привёл, работать не будет — счёту надо откуда-то взять доступ до своих проводок. Сам он рассчитать баланс никак не сможет.
Откуда он будет брать эти проводки? Из базы? Ну, тогда надо научить его общаться с базой, а это — прямое нарушение SRP. Придётся отпилить от него какую-то функциональность — либо по расчёту баланса, либо по работе с базой.
Если оставить в нём работу с базой, тогда непонятно, почему в нём — почему нам не иметь класс DbManager с методами GetTransfers(Predicate where), кроме которого, в общем-то, ничего и не нужно?
Если оставить в нём работу с расчётом баланса, а проводки отдавать снаружи, то получается, что мы завели целый отдельный класс для примитивов типа

Decimal static CalcBalanceForDate(Date date, allTransfers) 
 return (from t in allTransfers where t.Date <= date select t.Amount).Sum();

Зачем всё это делать, совершенно непонятно.
Всё, что нужно, прекрасно получается безо всяких объектов Account.