Позвольте мне начать с 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 и т. Д. Только промокод на сайте.
- Промокод для мобильных устройств, например, при первой загрузке мобильного приложения
- На основе местоположения
Учитывая, что таких типов заказов и правил очень мало, но на самом деле существует множество бизнес-правил.Проблема, как показано на диаграмме ниже.
У нас есть несколько микросервисов, которые хороши, но код процесса проверки очень монолитен, тысячи условий if / else вызывают несколько цепочек методов, что вызывает слишком много путаницы, потому что везде у нас естьусловие, основанное на клиенте / каналах / типе заказа / способах доставки и т. д. Все относится к слою Single Façade, который имеет методы из 1000 строк с несколькими, если не все.
Я предлагаю проект, в котором каждый клиент будет иметь своисобственный фасадный слой, который будет вызываться Channel / Client на основе FrontFacade (Routing Gateway).Каждый конкретный клиентский фасад может управлять и определять свои собственные конкретные правила и выполнять их в своем собственном определенном порядке.Будет отдельный уровень с независимой проверкой клиента и правилами, которые могут быть вызваны любым клиентом.
Я ищу комментарии / замечания / предложения по этому вопросу, чтобы определить лучший подход к рефракторингу с четким разделением, выполнением и очисткой.код без нарушения других бизнес-правил / проверки и т. д.
Примечание. За исключением 3rdPaties, все другие группы будут вносить коды для написания этого процесса проверки, а одна основная группа будет определять все общие правила / проверки / постоянства / последующие.и т. д.
