Как хранить бизнес и бухгалтерские правила?

Question

[EVGENY T.]

Вот дядя Боб(Мартин) в своей книжке про архитектуру пишет, что программе лучше всего опираться на бизнес-правила, которые меняются реже всего. Видать, дядя Боб не нюхал нашего ЦБ.

Каждый год выходят новые требования к финансовому и бух.учёту. Постоянно приходят задания типа сделай А, если счёт начинается на Х. Через год требуется, "но чтобы в 13 позиции счёта была 1". Я который год рисую эти загогулины вокруг единичек в счетах и тому подобного. Опираться на эту "бизнес-логику" нереально. Что-то можно вынести в справочники типа X->A, Y->B. Но тогда придётся писать справочник для КАЖДОЙ процедуры. А потом придёт новая инструкция и справочник станет бесполезен.

Как? Как хранить крючкотворные постоянно меняющиеся правила учёта и не превратить свой код в билиберду с кучей IF, масок счетов и т.д?

Comments

[Евгений Ромашкан]

Вопрос слишком общий чтобы давать какие-то конкретные ответы. Если у вас весь проект превращается в билиберду, значит вы не смогли нормально спроектировать архитектуру.

[Константин Нагибович]

Видать, дядя Боб не нюхал нашего ЦБ.

Он еще не нюхал наши банки. Анкета-заявление на кредит меняется по несколько раз в месяц.

Answer 1

[Пума Тайланд]

Именно поэтому 1с захватил рынок
Разработка очень мутная

Answer 2

[АртемЪ]

Каждый год выходят новые требования к финансовому и бух.учёту.

Они выходят гораздо чаще.

Постоянно приходят задания типа сделай А, если счёт начинается на Х.

Ну так делайте, это же ваша работа!

Как? Как хранить крючкотворные постоянно меняющиеся правила учёта

Правила учета хранить не надо!
Надо создавать софт который работает по этим правилам.
Если правила меняются - менять софт.

Answer 3

[Роман]

Если я правильно понял ту мысль дяди Боба (смотрел многие его выступления), то он имеет в виду inversion of control.

Но мне кажется, что лучше использовать функциональное программирование. А как лучше делать архитектуру приложения, чтобы можно было постоянно менять правила не меняя остальной код... погуглите Mark Bastian Bottom Up vs Top Down Design. Даже если я кругом неправ, то всё равно рекомендую посмотреть - очень вдохновляющее видео.

Comments

[Роман]

Контрольный в голову: сам Роберт Мартин уже несколько лет пишет на Clojure. И даже даёт лекции:
https://www.youtube.com/watch?v=Usxf3aLimtU

Answer 4

[Константин Цветков]

При изменении правил добавлять их новую реализацию.