Здравствуйте, Разраб, Вы писали:
Р>ну, если используется тестирование, всегда будет использоваться дважды (в проде и тесте).
Это тавтология. Эдак мы и метод Modulo2Equals0 будем считать "использованным дважды".
Юнит-тесты — это вспомогательный механизм. Сами по себе они не могут быть оправданием введения методов или чего-то ещё.

Р>с момента появления матча на свиче все больше убеждаюсь что его сложнее читать чем код с иф или кейс.
Вопрос привычки. В реальности лучше всего будут работать правила на DSL-языке, где для кусочно-линейной формы

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>>

Р>опять к вопросу тестируемости, в чистом ДДД логика отделяется от базы именно с этой целью.
Не, чистый ДДД — это просто алкоголизм, даже на наркоманию не тянет.
Логика отделяется от базы при помощи отделения логики от базы. Для этого достаточно превратить CheckoutV3 из void-метода в функцию, которая возвращает IUpdatable<Order>.
И мы тестируем не "SQL на живой базе", и не "SQL с тестовой базой", и не "сервис с моком репозитория в памяти", а чистую функцию.
Задача функции — породить корректный SQL по заданным параметрам. Всё.
То, что корректный SQL корректно обрабатывается на стороне СУБД, протестировано за десятилетия до нас.

Р>ПС это чисто мои придирки делитанта

Здравствуйте, Разраб, Вы писали:
Р>ну, если используется тестирование, всегда будет использоваться дважды (в проде и тесте).
Это тавтология. Эдак мы и метод Modulo2Equals0 будем считать "использованным дважды".
Юнит-тесты — это вспомогательный механизм. Сами по себе они не могут быть оправданием введения методов или чего-то ещё.

Р>с момента появления матча на свиче все больше убеждаюсь что его сложнее читать чем код с иф или кейс.
Вопрос привычки. В реальности лучше всего будут работать правила на DSL-языке, где для кусочно-линейной формы зависимости есть специальные решения.

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>>

Р>опять к вопросу тестируемости, в чистом ДДД логика отделяется от базы именно с этой целью.
Не, чистый ДДД — это просто алкоголизм, даже на наркоманию не тянет.
Логика отделяется от базы при помощи отделения логики от базы. Для этого достаточно превратить CheckoutV3 из void-метода в функцию, которая возвращает IUpdatable<Order>.
И мы тестируем не "SQL на живой базе", и не "SQL с тестовой базой", и не "сервис с моком репозитория в памяти", а чистую функцию.
Задача функции — породить корректный SQL по заданным параметрам. Всё.
То, что корректный SQL корректно обрабатывается на стороне СУБД, протестировано за десятилетия до нас.

Р>ПС это чисто мои придирки делитанта