Модель предметной области - объект сущности между слоями

Question

Может показаться, что вопрос оборван, но не смог найти ответ в SO.

Я занимаюсь разработкой простого приложения для обработки заказов.Совершенно битовая логика домена, поэтому я выбрал модель модели домена.Каждый Заказ имеет " OrderType ", называемый "Обычный" или "Экспресс".

У меня есть сущность Order, и я открыл свойство int с именем OrderTypeID, так как думал, что смогу сохранить Id OrderType в этом поле int.Работало нормально, но когда мне нужно было получить заказ, я мог заполнить целочисленный Id «Тип заказа», но мне нужно было показать «OrderType - Express or Ordinary» на экране.Таким образом, сущность Order, когда она возвращается к постоянству, идет с Id, но когда она возвращается, она должна стать текстом !!!!

Как мне сделать это в отношении моделирования объекта сущности Order, если я сохранюOrdertype как единое целое (может быть классом OrderType0, если да, как хранилище для класса "Order" разделит тип заказа так, чтобы я сохранил только Id?

любые точки будут оценены

Приветствия VJ

Answer 1

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

Первый вопрос: что, если вы добавите тип заказа. Придется ли вам вносить изменения в код, чтобы некоторые операции учитывали это? если это так, вы можете определить тип заказа как перечисление ... я сказал, что вы могли бы ... :) Тип заказа может быть настолько важным, что вы можете определить конкретный класс для каждого заказа в зависимости от их типа заказа и иметь общий базовый абстрактный класс и использовать наследование.

Второй вопрос: вам действительно нужно знать идентификатор вашей модели? Тип заказа 1, тип заказа 2 ... что-то значат для модели ... Я так не думаю. Вероятнее всего, чем во всей вашей бизнес-логике, которую вы предпочтете обработать, имеет OrderType.OrderType1 или OrderType.OrderType2. Enum в этом случае легче обрабатывать.

Третий вопрос: Вы можете задать себе тот же вопрос в своей базе данных (если это то, что вы используете как постоянство). Вам нужно отношение fK к таблице типов заказов? это имеет стоимость производительности. И вы, вероятно, использовали бы идентификатор для этого ... Не могли бы вы жить с типом данных БД с предопределенными значениями. Это еще одна тема, но она бросает вызов идее, что тип заказа может быть сущностью ...

И я мог бы рассмотреть другие вещи ... Есть много вещей, которые нужно учитывать:)

Наиболее распространенным решением было бы: использовать перечисление для типа заказа и иметь дело с преобразованием в хранилище, если логика операций заказа не является специфичной для типа заказа. Если не учитывать наследование и объектную ориентацию. Тип значения может быть вариантом, но у вас будет много атрибутов для типа заказа? Если нет, то нет значения типа. :)

Надеюсь, это поможет.

Answer 2

Несколько предложений / замечаний. OrderType звучит как тип значения, а не как сущность. Возможно, вы могли бы реализовать как перечисление? Что-то вроде

public enum OrderType { ordinary, express };

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

Даже если вы не можете / не хотите использовать enum, принцип тот же: используйте toString(), чтобы вернуть значащее значение. В обоих случаях это делает читабельное значение встроенным в класс OrderType. Вы также должны сделать экземпляры неизменяемыми (неявными с перечислением).

Предполагая, что Order является вашим агрегированным корнем, вы предоставите интерфейс, который принимает / возвращает экземпляр OrderType, а не целое число. Например:

class Order {
  //....

  public OrderType getOrderType() {...};
  public void setOrderType (OrderType orderType) {...}

  //...
}

НТН.