S>Если использовать DTO в Домене: Ваша бизнес-логика становится зависимой от API-контрактов. Если фронтенд попросит переименовать поле в JSON для удобства отображения, вам придется менять это поле в бизнес-логике, что может повлечь ошибки в расчетах. Внешний мир начинает диктовать правила внутреннему.

S>Если использовать Entity в Домене: Ваша бизнес-логика зависит от схемы базы данных. Если вы решите денормализовать таблицу для производительности или сменить PostgreSQL на MongoDB, вам придется переписывать бизнес-правила.

S>Правило архитектуры: Зависимости должны быть направлены внутрь. Слой Домена (бизнес-логика) должен быть самым стабильным и не зависеть ни от Базы Данных, ни от UI/API.

G>>При проектировании снизу вверх вы начинаете с компонентов, которые вам хорошо видны, но пока неясно, как они сочетаются друг с другом. Вы пишете компоненты по отдельности, тестируете их, а затем собираете в целую программу.

Q>class Customer: Entity
Q>{ 
Q>   [NoMapper] - что это здесь делает?
Q>   strring property{get;set;}

Q>   DateTime DateTime {get;set;}

Q>   string FomratDateTime
Q>   {
Q>     returt DatetTim.Format - //возвращаем в нужном формате
Q>   }
Q>}
Q>

Q>>class Customer: Entity
Q>>{ 
Q>>   [NoMapper] - что это здесь делает?
Q>>   strring property{get;set;}

Q>>   DateTime DateTime {get;set;}

Q>>   string FomratDateTime
Q>>   {
Q>>     returt DatetTim.Format - //возвращаем в нужном формате
Q>>   }
Q>>}
Q>>

Q>class CustomerCarTuple: ValueObject
Q>{
Q>  public Customer Customer {get;private set}

Q>  public Car Car {get;private set}
Q>}

Q>//метод сервиса
Q>public Ienumerable<CustomerCarTuple> GetCustomerCarReport()
Q>{
Q>  //
Q>  returt ...
Q>}
Q>

Q>>class CustomerCarTuple: ValueObject
Q>>{
Q>>  public Customer Customer {get;private set}

Q>>  public Car Car {get;private set}
Q>>}

Q>>//метод сервиса
Q>>public Ienumerable<CustomerCarTuple> GetCustomerCarReport()
Q>>{
Q>>  //
Q>>  returt ...
Q>>}
Q>>

G>Существует два подхода к проектированию программ и написанию кода: «сверху вниз» и «снизу вверх».

G>При проектировании сверху вниз вы начинаете с представления о программе в целом, возможно, о некоторых её компонентах и о том, как они взаимодействуют друг с другом, но сами компоненты ещё не до конца ясны. Вы реализуете высокоуровневую версию программы, которая вызывает упрощённые версии компонентов (которые могут ничего не делать), и постепенно углубляетесь в детали каждого компонента.

G>При проектировании снизу вверх вы начинаете с компонентов, которые вам хорошо видны, но пока неясно, как они сочетаются друг с другом. Вы пишете компоненты по отдельности, тестируете их, а затем собираете в целую программу.

G>Правильный подход к проектированию и написанию программы — «сверху вниз». Это не вопрос вкуса или предпочтений. Подход «снизу вверх» в корне ошибочен, и его не следует использовать.

G>На каждом уровне существует стремление в программировании «снизу вверх». Избегайте этого. Вместо этого начните с верхнего уровня, с main() или его эквивалента, и пишите так, как будто все части уже написаны. Добейтесь правильного вида. Вставьте заглушки или хардкод отдельных частей пока не добьетесь компиляции и запуска. Затем медленно продвигайтесь вниз, стараясь максимально упростить все. Не пишите ни строчки кода, которая не решает проблему, с которой вы столкнулись прямо сейчас. Тогда у вас может появиться шанс написать большую, работоспособную и долговечную программу.

G>При проектировании снизу вверх вы начинаете с компонентов, которые вам хорошо видны, но пока неясно, как они сочетаются друг с другом. Вы пишете компоненты по отдельности, тестируете их, а затем собираете в целую программу.

G>На каждом уровне существует стремление в программировании «снизу вверх». Избегайте этого.

G>При проектировании сверху вниз вы начинаете с представления о программе в целом, возможно, о некоторых её компонентах и о том, как они взаимодействуют друг с другом, но сами компоненты ещё не до конца ясны. Вы реализуете высокоуровневую версию программы, которая вызывает упрощённые версии компонентов (которые могут ничего не делать), и постепенно углубляетесь в детали каждого компонента.

G>>При проектировании сверху вниз вы начинаете с представления о программе в целом, возможно, о некоторых её компонентах и о том, как они взаимодействуют друг с другом, но сами компоненты ещё не до конца ясны. Вы реализуете высокоуровневую версию программы, которая вызывает упрощённые версии компонентов (которые могут ничего не делать), и постепенно углубляетесь в детали каждого компонента.

G>ctx.Stock.Where(s => s.Wharehouse == id).ExecuteUpdate(x => x.SetProperty(s => s.Quantity, s => s.Quantity - s.Reserved).x.SetProperty(s => s.Reserved, 0))
G>

G>Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде