Мы находимся в процессе реорганизации сложного потока аукционов в более функциональный шаблон стиля и обдумываем, использовать ли подход на основе промежуточного программного обеспечения или, возможно, шаблон на основе потока.
В настоящее время аукцион имеет много побочные эффекты на каждом шаге, ни одного экземпляра или класса чего-либо, что представляет аукцион в целом, и всегда добавляются новые бизнес-логи c, которые добавляют новые этапы для фильтрации, изменения и обогащения / тегирования свойств, связанных с аукционом.
Наше предложение состоит в том, чтобы провести реорганизацию аукциона таким образом, чтобы он соответствовал однонаправленному функциональному стилю для упрощения отладки и упрощения. Побочные эффекты и мутации должны быть либо ограничены, либо более контролируемы, у нас должен быть единый объект журнала или истории для каждого аукциона, чтобы его можно было легко отлаживать.
Один из подходов - следовать однонаправленной схеме:
Шаблон промежуточного программного обеспечения, такой как express, и каждый модуль выполняет свою бизнес-логику c и передает управление и историю только для добавления к следующей функции аукциона.
Или мы можем следовать архитектуре потока с помощью действий и редукторов, а также аукционного магазина или редуктора
Будет ли архитектура потока подходящей в эта ситуация? Или это слишком сложно и подход промежуточного программного обеспечения проще?
Наши главные мотивы - превращать постоянно растущую сложность бизнес-логики c во что-то, что можно легко протестировать и отладить вместе с быстрым облегчением производительность.