Как получить многоязычную модель домена?

Question

У меня есть много сущностей с 3 языковыми колонками: DescriptionNL, DescriptionFR и DescriptionDE (Описание, Информация, Статья, ... все на трех языках).

Моя идея состояла в том, чтобы создать четвертое свойство Description, которое возвращает правильное значение в соответствии с Thread.CurrentThread.CurrentCulture.TwoLetterISOLanguageName.

Но недостатком является то, что, когда у вас есть метод GetAll() в вашем репозитории для выпадающего списка или чего-то еще, вы возвращаете 3 значения на прикладной уровень. Такой дополнительный сетевой трафик.

Добавление языка параметров в службы домена для извлечения данных также не выполняется в соответствии с экспертами DDD. Причина в том, что язык является частью пользовательского интерфейса, а не домена. Итак, какой лучший способ получить ваши модели с правильным описанием?

Answer 1

Вы верны, указав, что язык не имеет отношения к модели домена. Если вам нужно манипулировать объектами или данными, вам нужно будет использовать некоторую каноническую форму этих данных. Это относится только к ситуации, когда значение имеет какой-либо смысл в вашем домене. Все, что есть только для классификации, может не интересовать вашу модель, но может быть полезно использовать каноническое значение.

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

Канонический подход, который использовался в одном из моих предыдущих проектов, имел наборы данных с описаниями на разных языках, но ключи были одинаковыми для каждого значения. Например, Mr является ключом 1, тогда как Mrs является ключом 2. Теперь на французском языке M. будет ключ 1, а Mme будет ключевым 2. Эти значения являются вашими организационными значениями. Предположим теперь, что у вас есть система A и система B. В системе A Mr - значение 67, а в системе B Mr - значение 22. Теперь вы можете сопоставить эти значения с помощью своих канонических значений.

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