Допустим, у нас есть простая команда CreateOrder
, и она может иметь 3 разных «уровня» криптографии.
Прозрачный уровень:
class CreateOrder
{
public function __construct(
string $id,
string $paymentMethod,
float $paymentAmount,
string $customerFirstName,
string $customerLastName,
string $billingAddressFirstName,
string $billingAddressLastName,
string $billingAddressStreet,
string $billingAddressCity
array $items // that's the only ninja
) {
// setters
}
}
Этот уровень должен раскрывать все возможныеполя заранее (которые могут достигать 30-50 или даже больше).Единственным неизвестным является список элементов, но в языках без структур вы просто не можете избежать этого (если мы не согласны с тем, что команды могут принимать объекты-значения).
Уровень группировки:
class CreateOrder
{
public function __construct(
string $id,
array $payment,
array $customer,
array $billingAddress,
array $shippingAddress,
array $items // that's the only ninja
) {
// setters
}
}
Этот уровень просто принимает массивы , как они были бы структуры .Это более загадочно, но позволяет легче модифицировать в случае, если мы хотим добавить еще одно поле в одну из групп.С другой стороны, мы должны проверить, были ли использованы правильные ключи, и, конечно, написать некоторую документацию, чтобы описать, какие поля являются приемлемыми.
Последний уровень - ниндзя:
class CreateOrder
{
public function __construct(array $data) {
// setters
}
}
Хорошо,если мы выбрали Сгруппированный уровень , мы уже можем принять ниндзя , потому что это та же проблема.Мы должны проверить все ключи и записать некоторую документацию, описывающую содержание полезных данных.
PS.Пожалуйста, не указывайте мне, что элементы в Прозрачный уровень могут быть добавлены в заказ с помощью отдельной команды, такой как AddItem .Давайте просто предположим, что я должен создать заказ, используя одну транзакцию и одну команду.
Мои вопросы тогда:
- Есть ли какой-либо шаблон / правило / книга / мнение, описывающее, какойлучший способ?
- Как сделать выбор (это действительно общий вопрос, но каждый раз, когда я сталкиваюсь с подобной проблемой, у меня возникает проблема с выбором, поскольку вариантов просто много, но недостаточно строгих правил, чтобыfollow)
- Может быть, вместо того, чтобы просто сохранять примитивы в полезной нагрузке сообщения, мы можем использовать объекты значений?
- Но, если мы решили использовать объекты значений, должна ли полезная нагрузка сообщения (объекты значений)быть полностью сериализуемым для примитивов?