Пользовательские c настройки для микросервиса

Question

Допустим, есть такая услуга A , которая отвечает за продажу яблок пользователям.

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

Если у нас было несколько разных конфигов (стоимость user / apple, скидка user / apple, пользовательский / яблочный допуск), какой будет хороший архитектурный подход для работы с отображениями пользователей / сервисов, какие-либо предложения?

Answer 1

Зависит от сложности. Я видел такую ​​сложную топологию микросервиса, которая разделяла ConfigurationService, и это было совершенно разумное решение. Пока ваш домен достаточно прост, такой параметр определенно принадлежит службе A.

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

Answer 2

Я думаю, что лучший подход - хранить это отношение в микросервисе услуги, потому что цена - это информация, которая напрямую связана с процессом продажи, а не что-то присущее пользователю. Таким образом, у меня была бы таблица или любой другой механизм магазина, в котором бы я связывал пользователей и цену, которую они имеют за каждый предмет. Например, в реляционной форме у меня будет таблица с (productId, userId, price)

Answer 3

Вы можете использовать карту данных для каждой страны с ConfigurationProperties.

Пример кода:

@ConfigurationProperties("a")
public class customConfiguration{

    private final Map<String, String> b= new HashMap<>();

    public Map<String, String> getB() {
        return b;
    }

}

И в вашем файле свойств:

a.b.c = 5
a.b.d = 10

, когда вы реализовать его, у вас есть карта

b = {c->5, d->10}

Answer 4

Это полностью зависит от того, как работает ваша бизнес-логика c. Микро-сервис - это просто способ доступа к бизнес-правилу. Предполагая, что у вас есть два вида правил: 1. RP1: спецификация продукта c Правила для всех параметров (правила для яблок, манго, апельсинов и т. Д. c). Этот набор правил, вероятно, может быть таблицей, которая ищет базовое значение продукт:

RU1: Заданные пользователем c Правила (Премиум-пользователи, Обычные пользователи и др. c). Другой поиск, основанный на USerID или пользовательском сегменте

]

Я бы попытался определить мои вычисления таким образом, чтобы можно было рассчитать RP1 и RU1 самостоятельно, а затем в сочетании. Таким образом, мой последний микро-сервис Служба A будет иметь (вход: продукт, пользователь, список параметров; вывод: параметр_значение_ списка). Служба A должна внутренне вызывать RP1 и RU1 и объединять выходы, используя третий набор правил. Это правило может быть правилом stati c, которое возвращает цену яблока в понедельник для Премиум-клиента = 1 * 0,9

ИЛИ другой подход, подобный комбинации базового значения и параметра: