"Правильность" построения системы

[BOAL]

В данном вопросе сквозит прикладной характер - успешность и неуспешность внедрения.
Формальные подходы и аудит частностей (кода, методик) - это отдельная песня, все можно и заключение получить. Но реально нужно знать одно - работает система или нет.
Если да, то ее архитектура успешна (на данный момент времени, пока не будет ясно, что масштабирование невозможно).
Если нет - то искать причины почему, составить список и устранить эти причины. Если трудоемкость и время на устранение чрезмерны (выходят за рамки проекта или суппорт запуска), то такое построение системы не удачно (или оценка проекта ошибочна в корне).

После анализа предпроекта строится и утверждается дизайн системы, как список бизнес-процессов и необходимых модификаций, настроек системы.
Ошибка в архитектуре бывает именно тут, причем фатальная, до провала проекта (провал - это не запуск в работу, ради чего все и делалось).

Решение для конкретного отчета - это уже мелочи на общем фоне - это уже не архитектура, а оптимальные алгоритмы конкретного мода.

Любой код можно сделать несколькими способами.
Он может быть краткий и красивый, но работать долго (не оптимально). Он может быть большой и запутанный, но работать жутко быстро (правильные селекты).
Чаще краткий и понятный код - оптимальный. Но не всегда.

Стандартный же функционал АХ бывает не приносит результата проекта (то есть запуска, как цели), а написанный урезанный сбоку, приносит (работает годами).
Все условно.

Заказчику без разицы (пока нет обновлений на новую версию), как внутри все сделано - работает? да! - критерий достигнут.

Это приводит нас к критериям оценки успешности проекта (часто их прописывают в регламенте опытной и промышленной эксплуатации). Если проект и система в них вошли - успех.

Если регламентов нет, критериев подавно, анализ и дизайн никто не делал, нет границ проекта и "че-то там пол-года делается", нет инструкций пользователя по всем блокам запуска, то это разводилово, поздравляю!