Здравствуйте, #John, Вы писали:

J>Покрывать код тестами, большого продукта, у которого есть план развития, который интенсивно развивается, выгодно бизнесу.
Это всё бесспорные утверждения.
Речь не идёт об отказе от тестирования. Речь идёт о бессмысленном коде абстрактных слоёв — вроде конверсии выхлопа СУБД в DTO, а DTO — в Entities.
Вот мы написали метод, который строит OrderEntity на основе OrderDTO — ок, теперь нам надо к нему написать серию юнит-тестов.
Если мы добавляем в наш Order новое свойство, то оно пролезло и в Entity, и в DTO, и в код по отображению — и теперь надо править существуюшие тесты, а также добавлять новые.
Ещё больше бессмысленной работы и нагрева атмосферы.

Здравствуйте, #John, Вы писали:

J>как вы боритесь с тем, что в методы entity, через параметры, в Domain слой протягиваютя классы из других слоев?

Если в бизнес логике нельзя использовать типы из других слоев, то можно либо выделить слой в отдельную сборку и следить, чтобы зависимости между сборками не противоречили архитектуре; либо использовать схемы зависимостей (но сам я этого не пробовал).

Если типы в принципе можно использовать, но нельзя в качестве параметров, то я не понимаю почему.

З
J>и в каком-то менеджере:
J>

J>rootAgreagete.Do("xxx","yyy", this.system1, this.system2, this.system3, this.logger, this.provider1, this.provider2, ....);

J>

тоже добавлю свои 3 копейки:
за что, собственно, отвечает обьект типа Entity ? не слишком ли много он на себя берёт, если ему нужно аж 8 зависимостей?

т.е. со стороны выглядит так, что он занят какими-то левыми вещами: бывают, конечно, случаи, когда нужно сделать то и это, но это относится, скорее, либо к слою application service либо абстрагируется событиями, для этого этому обьекту достаточно просто прокинуть событие, а уже вот тот компонент, который на это событие подписан и занимается тем, что вытягивает эти 8 зависимотей, что-то там делает и тому подобное

Здравствуйте, takTak, Вы писали:

T>З
J>>и в каком-то менеджере:
J>>

J>>rootAgreagete.Do("xxx","yyy", this.system1, this.system2, this.system3, this.logger, this.provider1, this.provider2, ....);

J>>

T>тоже добавлю свои 3 копейки:
T>за что, собственно, отвечает обьект типа Entity ? не слишком ли много он на себя берёт, если ему нужно аж 8 зависимостей?

Например, доменных сервис, о чем говорит название rootAggregate.

T>>З
J>>>и в каком-то менеджере:
J>>>

J>>>rootAgreagete.Do("xxx","yyy", this.system1, this.system2, this.system3, this.logger, this.provider1, this.provider2, ....);

J>>>

T>>тоже добавлю свои 3 копейки:
T>>за что, собственно, отвечает обьект типа Entity ? не слишком ли много он на себя берёт, если ему нужно аж 8 зависимостей?

S>Например, доменных сервис, о чем говорит название rootAggregate.

если исходить из того, что

The aggregate root is responsible for ensuring that the state is consistent with the business invariant.

то всё-равно получается, что over 8 зависимостей для обеспечения целостности и непротиворечивости предметной логики — это перебор, ну есть там какой-то доступ к хранилищу, этого же, в принципе, должно быть достаточно: вся проверка находится в этом же aggregate root , что ещё нужно -то ?