Оver-engineering - "зачем так сложно?"

[Raven Melancholic]

Клиенты-поставщики всего лишь небольшая часть проблемы классификации, выделения общих и различающихся признаков и совсем не являются уникальной проблемой не только Аксапты, но даже и не связанной вообще с ERP. Большинство знает афоризм про определение того, к какой науке относится явление (если зеленое, то.., если пахнет, то…).
Почему их разделили в разные справочники, а потом нарисовали код, который их обрабатывает как что-то похожее? Ну принято было такое решение, ему и следуют и нам тоже приходится следовать. Другие варианты были? Конечно были, многие в других системах видели реализацию других вариантов. Лучше другие варианты или хуже? В одних ситуациях лучше, в других хуже.
Достаточно давно встречал описание того, как определить является ли архитектор приложения профессионалом. Если на вопрос «как правильно реализовать вот эту штуку?» начинаются ответы, что «вот только так..», то это новичок, профессионал начнет свой ответ «это смотря с какой стороны посмотреть…».
Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.? Тем более, что один и тот же реальный контрагент может выступать в одних сделках как клиент, в других как поставщик, в третьих как акционер – вариантов множество.
Проблема в отсутствии какого-то единого подхода в разделении и объединении. Понятно, что управлять взаимоотношениями с клиентами, поставщиками, сотрудниками, акционерами это совсем разные задачи. Понятно, что есть какие-то общие задачи – те же взаиморасчеты (но со своими нюансами с каждой категорией).
Будет ли каждая категория выделена в отдельный справочник и реализованы механизмы обработки общих принципов в отдельном семействе классов с деталями, зависящими от справочника или все категории слиты в один справочник и разные механизмы будут основываться на типе договора или на каком-то другом признаке не особенно важно. Хотелось бы, чтобы подход в разных частях системы был единым. Если делаем сопоставление, что почему для клиентов/поставщиков механизм один, а для подотчетников другой? Можно сказать, что для последних есть отличия, но так они и для клиентов/поставщиков есть – почему тогда не разделили сопоставление для клиентов/потавщиков?