Разработка архитектуры приложения для системы каталогов / заказов

Question

Я должен написать систему, которая позволяет клиентам делать заказы продуктов.Существует существующее приложение, которое обрабатывает создание каталога (добавление, редактирование продуктов и т. Д.). Оно используется производителями для хранения данных о своих продуктах.Теперь мне интересно, как мне добавить функциональность заказа (у меня есть доступ к исходному коду приложения каталога и базы данных каталога).Функциональность заказа можно кратко описать следующим образом:

• клиент может войти в систему, чтобы сделать новые заказы, просмотреть старые
• производитель может войти в систему и увидеть новые заказы, сделанные клиентами, архив заказов
• Мидлман должен видеть все заказы, сгруппированные по производителю, чтобы он мог решить, отправлять их или нет

Я думаю о нескольких способах:

Создать новое приложение с новымбаза данных, которая содержит только заказы.

• товары в базе данных каталога и база данных заказов будут связаны парой [producent_id, product_id]

• в заявке на заявки.подключиться к базе данных каталога, чтобы показать информацию о продуктах

  Недостатки такого подхода, о котором я могу подумать, это то, что

  • не в состоянии выполнять статистические запросы типа "считать все заказы товаров изкатегории, которые сделаны из дерева "и т. д.

  Преимущества

  • четкое отделение от существующего приложения

Добавить функциональность к существующему приложению и использовать ту же базу данных

• У производителя есть еще одна опция в меню «Заказы»
• добавить новую функциональность для клиентов и посредников

Недостатки такого подхода, о котором я могу подумать, это

• невозможность, например, перемещения базы данных / приложений заказов на другой сервер

Преимущества

• возможность выполнять перекрестные заказы / запросы по каталогу

Я действительно не могу думать об этом.Я вижу плюсы и минусы в обоих направлениях, но не могу решить, что лучше.Есть ли у вас какие-либо предложения, может быть, третий способ?

PS технология будет рубин на рельсах

Answer 1

Лично я бы пошел на «добавить функциональность в существующее приложение».

Я не думаю, что вы хотите продавать приложение Order отдельно, потому что это полностью зависит от того, как строится ваше приложение Catalog / Product.

Разработка будет проще, не только доступ к базе данных, нотакже повторное использование существующей инфраструктуры улучшит вашу скорость разработки.

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

Гораздо сложнее выполнять перекрестные запросы к базе данных, которые не поддерживаются, чем оптимизировать приложение, когда вы замечаете некоторые реальные, измеримые проблемы с производительностью.

Так что, на мой взгляд, разработка ускоряет заработную плату предполагаемой производительностипроблемы.