Рефракторный монолитный код на основе нескольких каналов / клиентов - PullRequest
0 голосов
/ 17 февраля 2019

Позвольте мне начать с 1000 футов.

Это типичный процесс оформления покупок в электронной торговле, в котором несколько типов клиентов могут размещать заказы через несколько каналов.Большинство оставленных сайтов рис-1 - это каналы - Мобильный / Сайт / Служба поддержки / Точка продаж / 3-я партия и многие другие настроенные каналы.Заказы могут быть отправлены с различными типами доставки -

  • Премиум / Стандарт / Регулярный / NoHurryShipping / SameDayDelivery
  • Товар может быть небольшим (Жан / футболки / обувь и т. Д.)или большой (кровать / диван / матрасы и т. д.).Тип заказа также может быть нескольких типов - Обычный заказ / BuyOnlinePickInStore / BuyOnLineShipToStore
  • Множественный тип платежа (Наличные / Кредит (3-я партия CC / Карта частного уровня) / G-Pay / Apple-Pay / PayPal / GiftCard / Digital- Заработанные деньги)

У каждого клиента есть свой набор правил проверки и бизнес-правил для размещения заказа.Они также имеют другой уровень оркестровки для вызова правил / услуг, например, служба поддержки клиентов соберет все данные в своей системе и разместит заказ, позвонив напрямую в placeOrder.Online / Mobile позвонит создать / обновить и разместить заказ.Служба поддержки также хочет выполнить бизнес-правила в другом порядке по сравнению с заказом, размещенным с сайта / мобильного телефона.POS также имеет другой набор правил, которые хотят вызвать цепочку проверки или правила в другом порядке.Например, ниже приведены различные правила / функции для каждого клиента / каналов:

Служба поддержки

  • Они могут отказаться / Обновить количество любых элементов
  • Налоговые льготы
  • Дополнительные скидки
  • Может ли применяться специализированная акция по обслуживанию клиентов, т.е. плата за отказ от доставки.
  • Принимать только платежи - CC / Gift-Card
  • Многие другие бизнес-правила.

Онлайн

  • Может иметь малый / большой тип заказов
  • Принимать оплату для всех типов тендеров - CC / GC / Paypal / G-Pay / Apple-Pay и т. Д.
  • Только промокод на сайте.

Мобильный заказ

  • Может иметь малый / большой тип заказов
  • Принимать оплату для всех типов тендеров - CC / GC/ Paypal / G-Pay / Apple-Pay и т. Д. Только промокод на сайте.
  • Промокод для мобильных устройств, например, при первой загрузке мобильного приложения
  • На основе местоположения

Учитывая, что таких типов заказов и правил очень мало, но на самом деле существует множество бизнес-правил.Проблема, как показано на диаграмме ниже.Current design

У нас есть несколько микросервисов, которые хороши, но код процесса проверки очень монолитен, тысячи условий if / else вызывают несколько цепочек методов, что вызывает слишком много путаницы, потому что везде у нас естьусловие, основанное на клиенте / каналах / типе заказа / способах доставки и т. д. Все относится к слою Single Façade, который имеет методы из 1000 строк с несколькими, если не все.

Я предлагаю проект, в котором каждый клиент будет иметь своисобственный фасадный слой, который будет вызываться Channel / Client на основе FrontFacade (Routing Gateway).Каждый конкретный клиентский фасад может управлять и определять свои собственные конкретные правила и выполнять их в своем собственном определенном порядке.Будет отдельный уровень с независимой проверкой клиента и правилами, которые могут быть вызваны любым клиентом.

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

Примечание. За исключением 3rdPaties, все другие группы будут вносить коды для написания этого процесса проверки, а одна основная группа будет определять все общие правила / проверки / постоянства / последующие.и т. д.

Proposed new design

...