Допустим, у нас есть агрегированная корневая сущность типа Order, которая связывает клиентов и строки заказа. Когда я думаю о сущности порядка, более естественно представить ее как не определенную без идентификатора. Заказ без идентификатора, кажется, лучше представить как запрос заказа, чем заказ.
Чтобы добавить заказ в репозиторий, я обычно вижу, как люди создают экземпляр заказа без идентификатора, а затем репозиторий завершает объект:
class OrderRepository
{
void Add(Order order)
{
// Insert order into db and populate Id of new order
}
}
Что мне нравится в этом подходе, так это то, что вы добавляете экземпляр Order в OrderRepository. В этом есть большой смысл. Однако у экземпляра заказа нет идентификатора, и с точки зрения потребителя репозитория для меня все еще не имеет смысла, что у заказа нет идентификатора. Я мог бы определить OrderRequest как экземпляр порядка и добавить его в репозиторий, но это похоже на получение яблока из апельсина и последующее добавление его в список апельсинов.
В качестве альтернативы я также видел такой подход:
class OrderRepository
{
Order AddOrder(Customer customer)
// It might be better to call this CreateOrder
{
// Insert record into db and return a new instance of Order
}
}
Что мне нравится в этом подходе, так это то, что заказ не определен без идентификатора. Репозиторий может создать запись в базе данных и собрать все необходимые поля перед созданием и возвратом экземпляра заказа. Здесь неприятно то, что вы никогда не добавляете экземпляр заказа в репозиторий.
Любой способ работает, поэтому мой вопрос: должен ли я жить с одной из этих двух интерпретаций, или есть лучшая практика для моделирования вставки?
Я нашел похожий ответ, но для объектов значений: как мне добавить объект в коллекцию, поддерживаемую совокупным корнем. Когда дело доходит до объекта значения, нет никакой путаницы, но мой вопрос касается объекта с идентификатором, полученным из внешнего источника (автоматически созданный идентификатор базы данных).
