Здравствуйте, Sinclair, Вы писали:
В целом прекрасная иллюстрация как надо.
S>Введение отдельного метода оправдано там, где есть хотя бы одно из
S>а) он используется более 1го раза
ну, если используется тестирование, всегда будет использоваться дважды (в проде и тесте).
S>читается сильно лучше, чем
S>S>private decimal DiscountBy(long completedOrdersCount) =>
S> completedOrdersCount >= 5
S> ? 30
S> : completedOrdersCount >= 3
S> ? 20
S> : completedOrdersCount >= 1
S> ? 10
S> : 0;
S>
S>И уж точно это читается хуже, чем
S>S>private decimal DiscountBy2(long completedOrdersCount) =>
S> completedOrdersCount switch
S> {
>>= 5 => 30,
>>= 3 => 30,
>>= 1 => 10,
S> _ => 0
S> };
S>
с момента появления матча на свиче все больше убеждаюсь что его сложнее читать чем код с иф или кейс.
S>Всё, что нужно сделать — это передать эту функцию на сторону СУБД:
S>S>public void CheckoutV3(long orderId)
S>{
S> _merchantDb.Orders.ById(orderId)
S> .Set(o=>o.Discount, _discountCalculator.CalculateCustomerDiscount)
S> .Set(o=>o.State, o=> OrderState.AwaitingPayment)
S> .Update();
S>}
S>
опять к вопросу тестируемости, в чистом ДДД логика отделяется от базы именно с этой целью.
ПС это чисто мои придирки делитанта