DDD - модификации дочерних объектов в агрегате

1. Не оптимален, так как позволяет нарушить инвариант домена.

2. Это приведет к дублированию кода и ненужному взрыву метода.

3. То же, что и 1). Использование объекта значения не поможет сохранить неизменность домена.

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

Один недостаток 4 по сравнению с 2 - это непоследовательность. В некоторых случаях может быть полезно поддерживать определенную последовательность в отношении обновления позиций заказа. Может быть не сразу понятно, почему одни обновления выполняются через заказ, а другие через позицию заказа. Более того, если в строках заказа содержится 20+ свойств, возможно, это признак того, что существует возможность группировки среди этих свойств, что приводит к меньшему количеству свойств в строке заказа. В целом подход 2 или 4 хорош, если вы убедитесь, что операции атомарны, согласованы и соответствуют повсеместно используемому языку.

Есть пятый способ сделать это. Вы можете запустить событие домена (например, QuantityUpdatedEvent(order, product, amount)). Позвольте агрегату обработать это внутренне, пройдя список строк заказа, выбрав тот, у которого есть соответствующий продукт, и обновите его количество (или делегируйте операцию OrderLine, что еще лучше)

Событие предметной области - самое надежное решение.

Однако, если это излишне, вы также можете сделать вариант №2 с использованием шаблона Parameter Object - иметь одну функцию ModfiyOrderItem в корне объекта. Отправьте новый, обновленный элемент заказа, а затем внутри Order проверяет этот новый объект и вносит обновления.

Таким образом, ваш типичный рабочий процесс превратится во что-то вроде

var orderItemToModify = order.GetOrderItem(id);
orderItemToModify.Quantity = newQuant;

var result = order.ModifyOrderItem(orderItemToModfiy);
if(result == SUCCESS)
{
  //good
 }
else
{
   var reason = result.Message; etc
}

Главный недостаток здесь в том, что он позволяет программисту изменять элемент, но не фиксировать его и не осознавать этого. Однако его легко расширять и тестировать.

Вот еще один вариант, если ваш проект небольшой и вы хотите избежать сложности событий предметной области. Создайте службу, которая обрабатывает правила для Order, и передайте ее методу OrderLine:

public void UpdateQuantity(int quantity, IOrderValidator orderValidator)
{
    if(orderValidator.CanUpdateQuantity(this, quantity))
        Quantity = quantity;
}

CanUpdateQuantity принимает в качестве аргументов текущую строку заказа и новое количество. Он должен найти Заказ и определить, вызывает ли обновление нарушение в общем количестве Заказа. (Вам нужно будет определить, как вы хотите обрабатывать нарушение обновления.)

Это может быть хорошим решением, если ваш проект небольшой и вам не нужна сложность событий предметной области.

Обратной стороной этого метода является то, что вы передаете службу проверки для Order в OrderLine, где она на самом деле не принадлежит. Напротив, создание события домена перемещает логику Order из OrderLine. Затем OrderLine может просто сказать миру: «Эй, я меняю количество». и логика проверки заказа может происходить в обработчике.

как насчет использования DTO?

public class OrderLineDto
{
    public int Quantity { get; set; }
    public string Description { get; set; }
    public int ProductId { get; set; }
}

public class Order
{
    public int? Id { get; private set; }
    public IList<OrderLine> OrderLines { get; private set; }

    public void UpdateOrderLine(int id, OrderLineDto values)
    {
        var orderLine = OrderLines
            .Where(x => x.Id == id)
            .FirstOrDefault();

        if (orderLine == null)
        {
            throw new InvalidOperationException("OrderLine not found.");
        }

        // Some domain validation here
        // throw new InvalidOperationException("OrderLine updation is not valid.");

        orderLine.Quantity = values.Quantity;
        orderLine.Description = values.Description;
        orderLine.ProductId = values.ProductId;
    }  
}

• Единственная проблема здесь в том, что свойство OrderLines имеет общедоступный метод получения, и пользователь этого класса может добавлять элемент в коллекцию. Единственный способ, которым я могу придумать, как это предотвратить, - это скрыть получатель и добавить новый получатель, который вернет коллекцию DTO, если в этом есть необходимость.
• параметр id метода UpdateOrderLine может быть частью DTO, вероятно, с этим он будет работать лучше
• вероятно, вы можете принять OrderLine в качестве параметра напрямую вместо OrderLineDto (если вы хотите использовать некоторую OrderLine проверку перед переходом к Order).